[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