[Development] Compromise: Modified Lakos Rule

[Marc Mutz]

Hi,

I don't see how

On 06.09.24 22:34, Thiago Macieira wrote:
[...]
> In turn this means there's no support for throw-on-violations for Qt code in
> production.
[...]

necessarily follows, at least as long as we speak about a Qt-proprietary 
mechanism.

Another thing I neglected to mention is that there are two distinct 
steps here. The first is to change certain Q_ASSERT()s into Q_PRE() 
(say) precondition checks that optionally throw on violation. This has 
nothing to do with C++26/29 contacts.

The second step would be to piggy-back on the std contracts work. That 
realistically is out quite a few years for us, and likely will require a 
different syntax (placed on the function's declaration instead of into 
its implementation). So this is not what we need to factor in for Qt 6.

But I do note that it should be possible, if cumbersome, to support 
functions overloaded on nexcept/non-noexcept for a binary-compatible 
switch between the different build modes (e.g. by

   template <bool Throw = <build-dependent>
   R func() noexcept(!Throw);

Or using a mechanism similar to REMOVED_SINCE (which is also a way to 
remove noexcept that we have incorrectly added)).

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