On Sun, 16 Apr 2023 at 13:40, Edward Catmur <ecatmur_at_[hidden]> wrote:
>> > 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.

I fail to see the problem. It's as if you're suggesting that there's
some unknown specification challenge here, but we have the
specification
you speak of already, in the TS.

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

Yes? Neither of those needs other than pointers to them to work. Scope
guards are not like them.
You found two cases that presumably prove my statement wrong, but
(pointers to) those types can
be used as subobjects, that works fine, and they work with other
library types without problems, since
for them it's truly so that you don't need by-value subobjects of them.

Try harder.

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

Uhh.. you've never seen code that packages multiple individual objects
into a bunch, to pass them as one object to be processed
by a helper function? You can't fathom code where you'd take a pack of
callbacks and wrap scope guards on top of them, variadically?

Yeah, sure, I can show you that example you asked for. In my copious free time.

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

Well, gee whizz, that's an acceptable cost, compared to preventing the
use of scope guards as subobjects, which is not an
acceptable cost. If we have a solution that doesn't do that prevention
and solves the coroutine problem, I'm all ears.