On 4/14/23 14:18, Edward Catmur via Std-Discussion wrote:
>
> On Fri, 14 Apr 2023, 03:36 Ville Voutilainen,
> <ville.voutilainen_at_[hidden] <mailto:ville.voutilainen_at_[hidden]>> wrote:
>
> On Fri, 14 Apr 2023 at 01:16, Ville Voutilainen
> <ville.voutilainen_at_[hidden] <mailto:ville.voutilainen_at_[hidden]>>
> wrote:
> >
> > On Fri, 14 Apr 2023 at 01:12, Edward Catmur
> <ecatmur_at_[hidden] <mailto: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.

I think the point was that it is unexpected that this wouldn't work
without this workaround.