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/