[Development] Disavowing the Lakos Rule for Q_ASSERT

[Thiago Macieira]

On Tuesday 27 August 2024 10:29:05 GMT-7 Ville Voutilainen wrote:
> On Tue, 27 Aug 2024 at 17:15, Thiago Macieira <thiago.macieira at intel.com> 
wrote:
> > The point is that this putative mistake has no consequences, today. It
> > remains to be seen whether it will with contracts, when those come. When
> > contracts come, if those noexcept are a problem, then both libc++ and
> > libstdc++ will deploy a solution, which should suffice for us too. Until
> > then, I don't see a reason to deprive ourselves of any potential benefits
> > that the noexcept might bring.
> 
> What benefits?

TBH, it's actually very little. But little is not zero.

For the direct use of simple and not-so-simple inline functions, probably 
none. The compiler is good at seeing no exceptions are actually thrown.

It starts to get interesting for code that checks on the noexceptness of the 
content it's calling and use different algorithms. There aren't a lot of those 
outside of container copy, but they do exist.

There's the case of the complex sequence of inline functions where the 
compiler does not inline them all, in which case it may also not propagate the 
fact that no exceptions are actually thrown. In that case, the compiler will 
need to generate code to deal with exceptions that aren't there, which may 
hinder some optimisations. This is of course a QoI problem and I don't know 
what the state-of-the-art here is.

Then there are the out-of-line functions. But here I think we have a precedent 
in the library coding rule that we don't use Q_ASSERT to check on user input 
(preconditions). We may produce a qWarning, but usually just return or set an 
error condition. Plus, for most out-of-line functions either can't be noexcept 
anyway because they allocate memory somehow.

-- 
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/20240827/8b06bc88/attachment.bin>