On 29 May 2015 at 11:05, Peter Dimov wrote:
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.
You're not going to be able to tell the difference between .then and .next when given [](auto x) { ... }.
Surely with Expression SFINAE you can? But sure, it's sounding slower than a simple overload. And I'd like to retain VS2015 compatibility.
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))?
It's not that I don't like it, I don't see sufficient motivation for it.
Oh okay. In my situation, T and error_code are considered equals, only exception_ptr is exceptional.
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. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/