On 4/14/23 15:29, Ville Voutilainen wrote:
> On Fri, 14 Apr 2023 at 14:47, Andrey Semashev via Std-Discussion
> <std-discussion_at_[hidden]> wrote:
>
>>> > > If it's for RAII, then plain scope_guard should be fine (even if
>>> a bit misused; a class type is not a scope). scope_success and
>>> scope_failure would not make much sense as data members unless
>>> you're writing another success/failure scope guard class (what I
>>> meant by composability).
>>> >
>>> > That I can probably live with.
>>>
>>> ..except.. I don't think that's wise. I can easily imagine uses where
>>> I create an array of scope_fails, a tuple of scope fails, or even
>>> a vector of scope_fails. I find it perfectly reasonable to expect such
>>> composition to Just Work.
>>>
>>> Those can trivially be replaced with a single scope_fail referencing an
>>> array, tuple or vector of callbacks.
>>
>> I think the point was that it is unexpected that this wouldn't work
>> without this workaround.
>
> Well, it's easy enough to play with that, either using boost or by
> just using the TS implementation
> that is in libstdc++. The suggestion by Edward sounds semi-plausible..
> but the concern remains,
> especially for tuple, that the end result is much harder to use than
> just a straightforward tuple
> of scope_fails.

I'll add that the replacement code suggested by Edward is not equivalent
to the original as you lose the ability to (de)activate individual scope
guards. With scope guards supporting custom failure conditions, you also
lose that.