[Development] Disavowing the Lakos Rule for Q_ASSERT

[Thiago Macieira]

On Thursday 29 August 2024 13:33:55 GMT-7 Marc Mutz via Development wrote:
> On 29.08.24 17:31, Thiago Macieira wrote:
> > What I'd like to change is:
> > - for inline code, where the function's noexceptness is likely to be used
> > in a> 
> >   noexcept expression elsewhere and that causes slower code to be used
> 
> How does that square with being tool-checkable? That sounds like a very
> subjective and hand-waving argument that will cause haggling about every
> patch that uses the rule.

I don't think tool-verifiability is a requirement. Even then, it should be 
enough to use "doesn't allocate memory, doesn't call thread-cancellation 
functions" as a guideline.

> > - for out-of-line code, where the precondition is unverifiable anyway
> > (such as> 
> >    "you've passed a valid pointer")
> 
> *cough* https://codereview.qt-project.org/c/qt/qtbase/+/193707 *cough*

There's nothing there that mandates throwing exceptions. Neither Valgrind nor 
ASAN have that option now, which may mean something. Even if exceptions can be 
used to verify preconditions, the code surrounding it may not support 
exceptions, which makes things worse.

We are holding back gains now (small, but sometimes measurable) for a 
potential functionality that may exist in the future many years from today, 
which may work, and may have a backwards compatible solution.

I repeat that the standard library implementations are not that magic. 
Whatever extension they decide to use to enable exceptions, we can use too. 
And that's after we make an analysis of whether it's even worth for our 
content, which is highly exception-unsafe.

-- 
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/40380eff/attachment.bin>