[Development] Disavowing the Lakos Rule for Q_ASSERT

[Ville Voutilainen]

On Tue, 3 Sept 2024 at 18:36, Marc Mutz via Development
<development at qt-project.org> wrote:
>
> 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.

Thank you very much for writing that. I agree 100% with all of it. In
particular, the RAII part - there's barely
any reason _not_ to write exception-safe code, because it makes your
code also "return-safe", "break-safe",
"continue-safe", and shiver me timbers, "goto-safe", and also "fallthru-safe".

I may be more skeptical of that message sinking in. This is hardly the
first time I hear these "but I want want want
to make my functions noexcept, because it gives me perf benefits".
Without giving measurable perf benefits.
Except on clang. But elsewhere, the setup of a Language-Specific Data
Area that installs a terminating exception
handle into an exception table is not measurable. As a fun additional
point, it's by-default not visible on godbolt.
And this is neither the first time I hear "but I don't don't don't
don't want to write exception-safe code, because
I don't care for exceptions." While those are just terribly bad
reasons not to write exception-safe code and to
sprinkle noexcepts where they aren't really useful, it seems mightily
difficult to convince the people who believe
in them to change their ways.