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

[Thiago Macieira]

On Friday 6 September 2024 16:15:13 CEST Marc Mutz via Development wrote:
> 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.

One thing that Marc didn't mention is that we will be independent of the 
Standard Library's own ability to throw on its precondition violations. We 
will not count on it nor trust that it works, because it seems some or all of 
them have painted themselves into a corner that makes throw-on-violation 
impossible.

In turn this means there's no support for throw-on-violations for Qt code in 
production. Unless things change and that won't happen until the 
implementations have precondition support, we'll only use this for unit-
testing our APIs. And I really mean unit-testing: tst_QList can test its 
operator[], but tst_QObject shouldn't.

I don't think we'll prohibit this. But it will be a gun and there's your foot 
over there...

-- 
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/20240906/4696df4e/attachment.bin>