Boost logo

Boost :

Subject: Re: [boost] [next gen future-promise] What to call themonadicreturntype?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-30 08:43:45

On 30 May 2015 at 1:26, Peter Dimov wrote:

> >> > It's not that I don't like it, I don't see sufficient motivation for
> >> > it.
> Actually I've changed my mind and now I don't like it. It's a catch(...)
> without a rethrow, and while those are occasionally necessary, they are not
> likable.
> To be clear, I'm talking about the N4048's .catch_error that takes an
> exception_ptr, not an error_code.

I am sympathetic to this line of thought. Once you allow an
error_code, it becomes hard to imagine where treating exception_ptr
outcomes as just another value returned can be wise.

Ok, so if .next() filters for T, would .next_error() filter for

I can't say I like the name .next_error(). It suggests "the next
error", not the current one.

.on_error() maybe? But then .next() should be .on_value() instead

> > > I'm also not quite sure how it's to be used. Vicente's wording in N4048
> > > is a bit unclear.
> > >
> > > future<X> f1 = async( ... );
> > > future<Y> f2 = f1.catch_error( []( exception_ptr e ) { return
> > > Y(); } );
> > >
> > > What happens when f1 has a value?
> >
> > Surely for catch_error() one must always return the same type of future as
> > the input? Otherwise it couldn't work when f1 has a value.
> Vicente in N4048 says that it's not required to return the same type.

Oh. I don't know how that can work then. Maybe Vicente can clarify?


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at