On Fri, 14 Apr 2023, 03:36 Ville Voutilainen, <ville.voutilainen_at_[hidden]>
wrote:

> 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.
>

Those can trivially be replaced with a single scope_fail referencing an
array, tuple or vector of callbacks.

>