[Development] Disavowing the Lakos Rule for Q_ASSERT

[Thiago Macieira]

On Monday 26 August 2024 22:53:18 GMT-7 Marc Mutz via Development wrote:
> If we make the distinction between Q_ASSERT-as-precondition-check and
> Q_ASSERT-as-internal-invariant/state-check (with a new macro
> name/names), then I can agree to that. Note, however, that the example
> that sparked this discussion (View::slice(int, int)) remains
> noexcept(false) under this rule, too. Ditto op==(It, It).
> 
> I have tried to adjust
> https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews#noexcept
> accordingly. For offline reader convenience, it currently reads:

I still want to go further, with std::vector::operator[] as our example. If 
it's acceptable for them to use an assertion-in-noexcept in there, then it is 
for us, even if you and Ville consider it a mistake.

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.

-- 
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/5fca5c95/attachment.bin>