On Saturday, 15 July 2023 09:35:14 PDT Jason McKesson via Std-Proposals wrote:
> One of the reasons why maintaining exception-safety is so difficult is
> that C++ makes it really easy to *think* your code is exception safe
> when it really isn't. And you're trying to open up a second hole like
> that.

It may be worse than another hole.

Regular exceptions can only be thrown by the throw statement. Therefore, the
compiler can know whether any inline function has thrown and the noexcept
attribute allows it to know whether opaque ones will.

POSIX *synchronous* cancellations are similar to exceptions (it's implemented
by the same mechanism on Linux), so it knows that only a direct call to
pthread_testcancel() will cause the cancellation, or a call to a function
known to call that. Functions that can do so are marked: noexcept(false).

Windows structured exceptions are similar, but can also be thrown in critical
conditions like divisions by zero or crashes. That's usually so rare, and most
often only happen on bugs anyway, that they don't matter.

POSIX *asynchronous* exceptions can happen *anywhere*. They can happen inside
one statement. That means it's impossible to write RAII code without first
disabling asynchronous cancellations. That's why no one uses it.

I suppose Yuri's proposal would mean that they can't happen inside a single
statement, but only between statements. But I see no way to implement that
without a heavy overhead. Therefore, someone either needs to prove that the
overhead can be implemented with negligible cost, or then we accept opting in
to this mechanism.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering