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

I don't see an alternative design is possible. Other than removing scope
failure and success guards entirely.

>