On Fri, 14 Apr 2023 at 10:24, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
On Fri, 14 Apr 2023 at 16:05, Edward Catmur <ecatmur@googlemail.com> wrote:
> On Fri, 14 Apr 2023, 09:50 Ville Voutilainen, <ville.voutilainen@gmail.com> wrote:
>> On Fri, 14 Apr 2023 at 15:44, Edward Catmur via Std-Discussion
>> <std-discussion@lists.isocpp.org> 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
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

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