On Fri, 14 Apr 2023 at 15:35, Andrey Semashev via Std-Discussion
> >>> ..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.
That would stink, if you ask me. Such use cases collect multiple
results from multiple operations,
having failing scope_fails to receive them, and then disable those
scope_fails if the individual operations
I'm a bit confused as to what such cases would look like. Could you show an example?
We would be seriously hampering the facility by making it
non-composable, and I'm not all that
convinced that what we gain by doing so is worth it.
What we would gain is making it possible without breaking in the presence of coroutines and without excessive overhead.
We would also avoid any confusion over what it means to destroy a success/failure scope guard from a scope other than the one it was constructed from.