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.

>> 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.

> 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 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.