On Sun, 16 Apr 2023 at 13:40, Edward Catmur <ecatmur@googlemail.com> 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.
And that specification breaks with coroutines.
>> 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.
And you can take pointers to scope guards. Consider also immovable types like scoped_lock - those won't work with most library components.
>> > 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?
No, since you may as well wrap the lot into a single scope guard.
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.
Using scope_guard outside block scope is a code smell, though it can be justified in some rare cases. Using scope_success or scope_failure outside block scope would not pass code review where I work.
Meanwhile, using scope_success and scope_failure in coroutine block scope across suspension points is completely natural; the only problem is that it can break. We should not be adding footguns like that to the standard.
If we have a solution that doesn't do that prevention
and solves the coroutine problem, I'm all ears.
There's Andrey's solution, but the overhead is substantial.