Date: Fri, 14 Apr 2023 09:49:12 -0300
On Fri, 14 Apr 2023, 09:42 Ville Voutilainen via Std-Discussion, <
std-discussion_at_[hidden]> wrote:
> 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.
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.
>
std-discussion_at_[hidden]> wrote:
> 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.
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.
>
Received on 2023-04-14 12:49:31