On Sun, 16 Apr 2023, 16:44 Ville Voutilainen, <ville.voutilainen_at_[hidden]>
wrote:

> On Sun, 16 Apr 2023 at 22:41, Edward Catmur <ecatmur_at_[hidden]>
> wrote:
>
> >> >> If we have a solution that doesn't do that prevention
> >> >> and solves the coroutine problem, I'm all ears.
> >> > There's Andrey's solution, but the overhead is substantial.
> >>
> >> I don't quite follow how that overhead is avoidable just by wrecking
> >> the composability of these types, or at all.
> >
> >
> > To recap: the compiler knows when a destructor is being called by normal
> or exceptional scope exit. Since the compiler and library are written
> together, the former can pass that information to the facility by private
> ("magic") means. However, this may be trickier to implement if the
> destructor of another class intervenes.
>
> Right. The "good old" "let's have multiple destructors, and give them
> parameters that tell them who's who". That doesn't compose,
> so the conclusion is to desperately pretend that we don't need composition.
>

I'll try to survey existing code to see where and whether composition is
actually used.

Nothing good comes out of that.
>
> >> Perhaps we should entertain a separate scope fail/success type that is
> >> coroutine-aware, and leave the TS ones
> >> without that overhead.
>
> This.
>

Agreed, but only if the dangers can be made abundantly clear, via
documentation, naming, deprecation and/or ill-formedness.

>