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
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
