On Fri, 14 Apr 2023 at 10:24, Ville Voutilainen <ville.voutilainen_at_[hidden]>
wrote:

> On Fri, 14 Apr 2023 at 16:05, Edward Catmur <ecatmur_at_[hidden]>
> wrote:
> >
> >
> >
> > On Fri, 14 Apr 2023, 09:50 Ville Voutilainen, <
> ville.voutilainen_at_[hidden]> wrote:
> >>
> >> On Fri, 14 Apr 2023 at 15:44, Edward Catmur via Std-Discussion
> >> <std-discussion_at_[hidden]> wrote:
> >>
> >> > If you allow tuple, then you have to allow vector, and since a vector
> can be moved without moving its elements you then have the problem of
> (success/failure) scope guards being destroyed from a scope other than the
> one they were constructed in.
> >>
> >> Then don't do such moves.
> >
> >
> > Fine, and how do we specify the facility that such moves have
> undefined/unspecified behavior but the cases we want to allow do? I can't
> see a way.
>
> We don't. If I want to store these things in a vector and move the
> vector around, that's my business. I'll need to disable the elements
> if the vector
> has been moved. If I want to wrap these things in a shared_ptr after
> allocating them dynamically, and then store those shared_ptrs into a
> vector,
> that's my business, and none of the library's to prevent.
>

And we need to know what happens when you do that, or know that it is
unspecified. What I'm saying is that the behavior needs to be specified, or
explicitly unspecified. If the behavior is specified in terms of
uncaught_exceptions(), that takes care of it, but leaves the coroutine case
broken.

>> We have various book entries about "how to
> >> prevent dynamic allocation of objects of your type"
> >> and "how to prevent objects of your type being used as subobjects",
> >> and they're always weird, never work well, and are
> >> always wrong to begin with. If we are in a tar pit of a design that
> >> suggests such limitations to be necessary, we need
> >> to climb out of it, and fast.
> >
> >
> > Weird doesn't matter, these are library types.
>
> No library type prevents using it as a subobject, or prevents itself
> completely from working with other library types. It sure as hell
> matters.
>

std::typeinfo? std::chrono::time_zone?

> Working well can be dealt with by the vendor since these are library
> types. Wrong - maybe, but this is a scope guard! The name indicates it
> should be used in a scope.
>
> Yeah, which does include packaging them any which way I please and
> passing them down to helper functions for further processing,
> or just having a collection-bunch of them in a scope, rather than
> having to have individual objects of the scope guard type directly,
> without
> the possibility to bunch them.
>

I've never seen code where that would actually be useful.

> I don't see an alternative design is possible. Other than removing scope
> failure and success guards entirely.
>
> The current design in the TS is just fine. It specifies how the
> destructor of these things works, and tells you clearly enough what
> happens if you move a container of these things around into a scope
> that has a different value for uncaught_exceptions() than
> the original scope had.
>

It's not fine, because it breaks with coroutines.