pon., 17 kwi 2023 o 14:11 Andrey Semashev via Std-Discussion
<std-discussion_at_[hidden]> napisał(a):
>
> On 4/17/23 14:49, Marcin Jaczewski wrote:
> > pon., 17 kwi 2023 o 13:44 Andrey Semashev via Std-Discussion
> > <std-discussion_at_[hidden]> napisał(a):
> >>
> >> On 4/17/23 14:36, Andrey Semashev wrote:
> >>> On 4/17/23 14:11, Marcin Jaczewski via Std-Discussion wrote:
(...)
> >>>
> >>> This means every smart pointer and container and any other user-defined
> >>> type that uses pointers as members would have to be updated for this to
> >>> work. This is a big ask.
> >>
> >> Also, I wonder how things like shared_ptr and unique_ptr<T[]> would work
> >> with this.
> >>
> >
> > Do even langage need to define behavior for it?
>
> You're defining a new operator (or even a set of operators), so yes, as
> a matter of fact the core language and the standard library has to
> define the behavior of these operators in each and every case, scope
> guards or not. Does the language guarantee that `T::operator unwind`
> will be called by unique_ptr<T[]> for every member of the array? How
> would that be implemented? What about shared_ptr<T>? What if there are
> two shared_ptrs pointing to the same object and only one of them is
> destroyed due to an exception?
>

Operators are used only for stack variables, nothing else.
You can call them directly as any other operator or function.
But it will not propagate through pointers, you will need to manually
propagate it.
Same like copy work.

Std can define on its own discretion whether some smart pointer
propagates it or not.
`unique_ptr` could be considered, `shared_ptr` should not as this will
be a coin toss what behavior
you get ("was this last shared pointer or only first of many?")

> How does this new operator interact with virtual functions and base
> classes? Do you allow the operator to be =deleted? If so, what does it
> mean? Is the object now indestructible? (Because whether there will be
> an exception or not is a runtime property, not compile-time.)
>

This is not a problem as this operator only is applied to stack variables.
This is determined at compile time what type it is.
If called manually then normal overload rules apply as for any other operator.
The only thing to figure out is that it should be allowed to be
supplied by base class only,
like other operators can be.

`=deleted` is good question, and I think it should be supported.
probably if you "ban" exceptions unwind, class could only be placed in
`noexcept`
 functions, if you ban normal unwind then it can't be a local variable.

But you can still composite types like this, simply `= default` will
stop working.

> There are likely a lot of other questions such a proposal needs to answer.
>
> > How do you want scope guard for variables that are not linked in any
> > way to scope? Is even one correct answer for this?
>
> There is an answer in the current TS - the scope guard calls its action
> when its destructor is called. scope_success/scope_fail also add the
> logic around uncaught_exceptions(), which, although is not working as
> desired with coroutines, is still rather simple and straightforward.
>

I do not think this is "simple", see `shared_ptr` when its lifetime is
undetermined
locally and destructor `uncaught_exceptions` unrelated to the value
from the point of creation.

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