Boost logo

Boost :

Subject: Re: [boost] [next gen future-promise] What to call the monadicreturn type?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-28 21:21:01

On 28 May 2015 at 21:34, Peter Dimov wrote:

> > > I wasn't suggesting removing .then, just adding .next. It's useful when
> > > I need to perform the same action regardless of whether I got a value or
> > > an exception.
> >
> > I'm a bit confused. If you want some action to occur regardless, you
> > surely ignore the future you are passed in your continuation?
> >
> > Or by next(), do you mean that the continuation must fire even if no value
> > nor exception is ever set, and is therefore fired on future destruction?
> What I mean is:
> .then( []( future<T> ft ) { /*...*/ } )
> Used when I want to, for instance, send ft to someone via message
> passing
> .next( []( T t ) { /* ... */ } )
> Fires when ready() && has_value(). Used when I only care about results.
> So, for example, when I do
> auto r = async(f1).next(f2).next(f3).next(f4).get();
> I don't care which of the four steps has failed with an exception.

Ok, let me rewrite that so we know we are on the same page:

future<T>.next(R(T)) is the same effect as:

future<T>.then([](future<T> f){
    return R(f.get()); // f.get() rethrows any exception, doesn't
execute R(T)

Your .next() is the same as Vicente's expected.bind() right?

If so, I was going to have .then() cope with a R(T) callable, but
that requires metaprogramming to examine the input and determine the
overload. A .next(R(T)) might be easier on build times.

I think I saw you didn't like Vicente's catch_error(E)? Was there a
reason why? Is there anything wrong with a .next(R(E))?


ned Productions Limited Consulting

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