On Fri, 14 Apr 2023 at 15:35, Andrey Semashev via Std-Discussion
<std-discussion_at_[hidden]> wrote:
> >>> ..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
succeeded. 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.