pon., 17 kwi 2023 o 12:35 Andrey Semashev via Std-Discussion
<std-discussion_at_[hidden]> napisał(a):
>
> On 4/17/23 13:27, Marcin Jaczewski via Std-Discussion wrote:
> > niedz., 16 kwi 2023 o 21:44 Ville Voutilainen via Std-Discussion
> > <std-discussion_at_[hidden]> napisał(a):
> >>
> >> 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.
> >>
> >> Nothing good comes out of that.
> >>
> >
> > Why are multiple destructors bad? Especially if they were handled like
> > `const` overloads.
> > Besides, if a new destructor is no-go, why not add a new operator that
> > simply is called before the destructor?
> > like `operator unwind()` that is called before a proper destructor is
> > used in case of unwind.
>
> It doesn't matter how you name it. If it doesn't work through other
> types (e.g. if the scope guard is a member or accessed through a
> pointer) then we have a problem with composability. If it does work,
> then we're back to the status quo, since the operator will be called
> under the same conditions as the destructor, and therefore it will need
> to check for uncaught_exceptions().
>

`operator unwind() = default;`?
And if it's not a direct member then we have the same problem with
composible as "copy",
that I suppose is solved problem?

You miss an important thing `unwind` will be called only when an
exception unwind code.
For the `scope_fail` destructor could be even noop if we use this new operator.
I probably could name it more clearly like:
```
operator throw_unwind();
operator normal_unwind(); //for scope success
```
etc.

As this is new function we could implicitly add default implementation
to all types.
where if there is nothing to do, no code will be generated (like for
trivial destructible).
As this is an operator as any other, you can call it directly to
propagate it in containers.



> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion