[Development] Disavowing the Lakos Rule for Q_ASSERT

[Marc Mutz]

On 31.08.24 20:01, Ville Voutilainen wrote:
> On Fri, 30 Aug 2024 at 19:21, Thiago Macieira <thiago.macieira at intel.com> wrote:
>> For the non-simple cases, we may need two macros, one that expands to:
>>
>>    noexcept(noexcept(std::string_view{"", 1}))
>>
>> and the other that expands to the pre() specifier.
> 
> Right. Maybe
> 
> void f(int x) Q_NARROW_CONTRACT_NOEXCEPT Q_PRE(x >= 0) ;
> 
> and then, if contracts are enabled, that noexcept expands to nothing,
> and if contracts are disabled,
> the pre expands to nothing and that noexcept expands to a noexcept.

I'm really doubting the wisdom of adding another dimension of build to 
Qt. We already have release/debug, and Q_NARROW_CONTRACT_NOEXCEPT would 
mean an orthogonal build mode. So on Windows we'd need four builds per 
compiler. Assuming, as I do, that that feature will be in high demand by 
users once available. Nothing we haven't done before (Qt 3 had 
debug/release × multi/single-threaded), but just like Qt 4 ditched the 
non-MT build mode, I expect we'd be ditching the 
non-contracts-checking-supporting (noexcept enabled) build mode ere 
long, because it turns out to be too much of burden to carry around with 
(presumably) too little a benefit.

As is well-known, not all users of Qt build Qt from scratch. Think Linux 
distributions. The Lakos Rule ensures that a single build can be used 
for both checked and unchecked contract mode, with the control lying in 
the hands of the owner of main(), where we seem to agree it belongs.


I also question the notion of "we don't do exceptions in Qt" popping up 
between the lines in this thread. We _do_ support them in QtCore and 
QtTest, and it's Core you're proposing to plaster with noexcept. 
Exception-unsafe code is also prone to Static Analyzer complaints, and, 
once again, legislators are working on forcing software companies to do 
more for security, not less (and one of the ways TQtC has decided to 
take this is to listen to SA tools more (Axivion, but Qt is also covered 
by Clang-SA and Coverity)). I believe one goal of contracts is to make 
C++ an (optionally) checked language.

We need _more_ exception (= resource) safety and not less. Exception 
safety doesn't mean QT_TRY and QT_CATCH, but, in 95% of cases, RAII, and 
RAII helps also against laissez-faire coding practices (see 
https://codereview.qt-project.org/c/qt/qtbase/+/551854 for a recent 
example) that have nothing to do with exceptions. Build-conditional 
noexcept and ignoring exception safety is heading into the opposite 
direction of where I, at least, see that Qt needs to go. Besides, libc++ 
recently ditched their build-conditional noexcept approach, AFAIK. We 
needn't make mistakes others have already done for us.
	
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