[Development] Compromise: Modified Lakos Rule (was: Re: Disavowing the Lakos Rule for Q_ASSERT)

[Marc Mutz]

Hi,

Over lunch at QtCS, Thiago and I have reached common ground on this.

Seeding the proposal:

We continue to follow the Lakos Rule, but if slapping noexcept on a 
narrow-contract function demonstrably improves "things" (performance, 
code size?) significantly, then you MAY slap a noexcept on the function, 
provided it's hidden behind a macro. This should be an exception (no pun 
intended): not more than a dozen or so per year.

We have Q_DECL_NOTHROW and Q_DECL_NOEXCEPT that we could repurpose for 
this, but since we maintain these for backwards compatibility, we 
probably don't want do that and change the existing meaning (always 
noexcept) under existing users.

So realistically, we'd need a new macro.

We also seem to agree on the desire to make precondition checks use a 
macro other than Q_ASSERT, and also on having that optionally throw, and 
use it in negative testing.

Details still open:
- name of the macros
- default (empty or noexcept; depending on debug/release?, developer-build?)
   - determines what we can do with per-existing noexcept's that violate
     the Lakos Rule
- anything I might have forgotten

Discuss :)

Thanks,
Marc


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*.
> 
> 
-- 
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