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