[Development] Disavowing the Lakos Rule for Q_ASSERT

[Thiago Macieira]

On Tuesday 3 September 2024 17:34:20 CEST Marc Mutz via Development wrote:
> 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. 

No, we don't. The throwing-assertion mode is non-standard and binary-
incompatible build mode of the Standard Library itself. Therefore, anyone who 
wants ti must compile all of C++ from source. Qt is just not an exception to 
that requirement.

We can mark our narrow-contract functions noexcept if std::optional::operator* 
or operator-> are noexcept. The Standard says:

  Preconditions: *this contains a value.
[http://eel.is/c++draft/optional.optional#optional.observe-1]


> Assuming, as I do, that that feature will be in high demand by
> users once available. 

I disagree with that assumption. I agree that checking preconditions will be 
in high demand, but not *throwing* assumptions. Users can still benefit from 
checked contracts with a termination handler and proper backtrace of the locus 
of the violation.

Either way, the point is moot.

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

Given the precondition stated in my first paragraph of the reply, I think it'll 
be the opposite.

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

We partially support them in the container classes, indeed. But we don't test 
them so anyone trying to use them right now is asking for trouble. To enable 
throwing contract violations requires first fixing all of that.

The object model and event loop is not exception-safe. We tried a little 
during the Symbian days but mostly have given up. We give lip service to the 
problems where possible, but we don't go out of our way to ensure exception 
safety or that we don't leak resources in case of exceptions (including thread 
cancellation). In some cases, we *know* it will crash.

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

You're welcome to do all of that work. I'll even review the patches and 
provide feedback. But I don't think it's a good use of our time, especially 
when we call out to non-Qt code that isn't exception- or even unwind-safe 
(q.v. the crashes on macOS on ARM64).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCAI Platform & System Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20240904/f7301d5a/attachment.bin>