Re: [scope] scope_fail is unimplementable

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-04-06 21:51:17

On 4/6/23 21:26, Andrzej Krzemienski via Boost wrote:
> Hi Everyone,
> It is my understanding that the reason scope_fail was left to die in the
> C++ Extensions for Library Fundamentals v3 was that it is not
> implementable.

I'm not sure what you mean in the "left to die" part. Do you mean that
these facilities are being deprecated?

> One cannot detect if the scope is being left due to an
> exception thrown from within the scope. Observing the number of uncaught
> exceptions in the constructor and in the destructor will not work, given
> that we now have coroutines that can be suspended and then resumed in
> another thread (with a different number of uncaught exceptions), or even in
> the same thread but at some later point, when the number of uncaught
> exceptions has changed.
> 
> The enclosed example illustrates how a scope_fail fails to call the
> callback when an exception is thrown from a coroutine. It uses Lewis
> Baker's CppCoro implementation of a generator.
> 
> The only reliable way to call a callback when the scope is left due to an
> exception is through using the explicit call to `deactivate()` function. It
> is more verbose, but reliable.

I must say I have no experience with coroutines, but my understanding is
that they are basically incompatible with any mechanism that relies on
thread-specific state, including the uncaught exceptions counter. Thus I
wouldn't say scope_success/scope_fail are unimplementable - they clearly
are - but that they are incompatible with coroutines. That is, these
scope guards will work as expected as long as you don't switch
coroutines within the guarded scope.

I admit this is a notable limitation, and I will document it. But I do
not consider this limitation fatal, as there is plenty code out there
that doesn't use coroutines - I'd even say, much more code than that does.

Thanks for pointing this out.