[Development] Disavowing the Lakos Rule for Q_ASSERT

Marc Mutz marc.mutz at qt.io
Mon Aug 26 21:55:04 CEST 2024


On 26.08.24 19:56, Thiago Macieira wrote:
> The Lakos Rule says that methods that only methods with wide contracts should
> be noexcept. That is, if your method has a precondition, it should not be
> noexcept.
> 
> This is apparently predicated on the fact that the preconditions will be
> implementable as C++ contracts some time in the future and that some compilers
> or compilation modes may turn contract verifications into runtime checks.
> Moreover, said checks can be implemented by throwing an exception indicating a
> contract violation. Alternatively, an application could replace the Qt
> assertion handler with one that throws (which is currently not possible
> because qt_assert is noexcept, therefore this replacement is not supported).
> 
> I'd like to request Qt code not obey that rule. In my opinion, it's a defect
> in the contract implementation rather than on Qt code. The *pre* condition
> indicates something that must be true before the method is called and
> therefore the method's own noexcept specification does not apply *yet*.

I don't see a proposal for an alternative rule in the above. Please 
provide a) a new rule and b) rationale for it. Bonus points for being 
implementable in a static checker like Clazy or Axivion.

Background: The Lakos Rule has been the status quo for the last decade 
in C++ and Qt. It is easy to explain and should be pretty 
straight-forward to check. I don't think we as the Qt project are 
qualified to come up with a rule that differs from what std is doing, so 
I strongly suggest not to try. Alternatively, we need _very_ good 
reasons to diverge from what std is doing, not just one developer's hunch.

Allowing Q_ASSERT to throw into QtTest would be a big step towards 
better testing of failure conditions, something that surely becomes more 
important over time as pressure from legislators on unsafe-memory 
language libraries increases. Any function in-between that's incorrectly 
marked as noexcept prevents that check from working, until it can be 
fixed in the next major release (removing noexcept is BiC). So not only 
do we have _no_ incentive to diverge from std, we also have a rather 
large incentive to keep doing what std is doing.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at qt.io> (he/his)
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B



More information about the Development mailing list