[Development] Disavowing the Lakos Rule for Q_ASSERT

Thiago Macieira thiago.macieira at intel.com
Fri Aug 30 03:57:11 CEST 2024


On Thursday 29 August 2024 18:14:37 GMT-7 Ville Voutilainen wrote:
> It's very unlikely to be anything other than an incompatible build.

I presume you are answering that for the standard library.

If the standard library will have an incompatible build, then by definition 
ours that depends on the regular build is not compatible with it.

> So, if you wish to add more noexcepts into our code where we don't
> demonstrably desperately need them,
> and those noexcepts are on narrow-contract functions, at least add
> them with a macro.

I don't see the point of restricting to performance-critical code. Either we 
use the macro everywhere where we apply a noexcept where preconditions exist, 
or we don't.

Said macro should be tied to the precondition itself, if we can. I haven't 
looked at the syntax: can one macro in one location expand to preconditions-
or-noexcept-or-both?

-- 
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/20240829/d0d4158a/attachment-0001.bin>


More information about the Development mailing list