Re: [boost] [next gen future-promise] What to call the monadicreturn type?

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))?

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/