On Fri, 14 Apr 2023 at 01:16, Ville Voutilainen
<ville.voutilainen_at_[hidden]> wrote:
>
> On Fri, 14 Apr 2023 at 01:12, Edward Catmur <ecatmur_at_[hidden]> wrote:
>
> >> > 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).
>
> That I can probably live with.

..except.. I don't think that's wise. I can easily imagine uses where
I create an array of scope_fails, a tuple of scope fails, or even
a vector of scope_fails. I find it perfectly reasonable to expect such
composition to Just Work.