On Thu, 13 Apr 2023 at 18:50, Ville Voutilainen <ville.voutilainen_at_[hidden]>
wrote:

> On Fri, 14 Apr 2023 at 00:44, Edward Catmur <ecatmur_at_[hidden]>
> wrote:
>
> >> Warning users that these things don't work in coroutines seems like a
> >> palatable solution to me.
> >
> >
> > It seems like a non-solution to me. Users will do it anyway, then get
> confused and complain when it doesn't work. Coroutine libraries will come
> up with solutions like the above, but independently and without
> interoperability, so if you're using the folly scope guards you have to use
> folly coroutines and vice versa, and the same for boost etc.
> >
> > The thing is, it is possible for scope guard destructors to detect how
> they were called. We just have to give up composability, which honestly
> doesn't seem like that much of an issue - why would you want to put a scope
> guard inside another object or in dynamic storage?
>
> To give RAII semantics to types that don't have them internally,
> without having to write holder types. If that's the price of getting
> coroutines to work, to lose the ability to do that, then you can burn
> coroutines for all I care.
>

If it's for RAII, then plain scope_guard should be fine (even if a bit
misused; a class type is not a scope). scope_success and scope_failure
would not make much sense as data members unless you're writing another
success/failure scope guard class (what I meant by composability).