[Development] Disavowing the Lakos Rule for Q_ASSERT

[Thiago Macieira]

On Thursday 29 August 2024 20:17:57 GMT-7 Ville Voutilainen wrote:
> Yes. Here's an example of the syntax for you:
> 
> void f(int x) noexcept pre(x >= 0);
> 
> The contracts go after everything else, pretty much. Be aware, though,
> that a trailing return type
> goes after a noexcept-spec, and contracts go after a trailing return type.

Thanks. It also looks like it comes after the requires clause but I can't find 
where requires fits in relation to noexcept...

> ..so I guess I should adjust that first "Yes." to be "Not really."

More like "shmaybe"

It will work for the simple cases; it's the hard ones we'll need to address. 
It's possible we'll have an override/final virtual function that has 
preconditions. Because it's virtual, it's unlikely to be inlined. But it's 
also unlikely to be performance-critical, so its noexceptness is probably not 
a problem. It's also an unlikely API, because a virtual override noexcept 
implies the base is noexcept, so it's expecting the contract to be wide.

Aside from the obvious "the object is not corrupt".

For the non-simple cases, we may need two macros, one that expands to:

  noexcept(noexcept(std::string_view{"", 1}))

and the other that expands to the pre() specifier.

We could bring back the Q_DECL_NOTHROW for the former, because *we* don't 
throw nor call a function that throws, but an exception may be generated 
anyway. Because that noexcept expression is currently noexcept(true) for all 
major Standard Libraries whose headers I can see, there is no behaviour change 
and no incompatibility.

-- 
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/20240830/f1bf5c9f/attachment.bin>