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

On 28 May 2015 at 14:38, Peter Dimov wrote:

...

I see that you want to be able to store error_code or exception_ptr. Wouldn't the interface of expected> be enough?

future<T> already adds the ability to store exception_ptr. There is no need to store another exception_ptr in the value. Niall's type is exactly equivalent to future>, as I already said (twice).

exception_ptr unfortunately must always do an atomic write to memory. That always forces code to be generated, and very substantially reduces optimisation opportunities because state must be reloaded around the exception_ptr. This, and the mandatory memory allocation, is a big reason current futures are not suitable for high performance ASIO. I also want a big semantic change that error returns are not exceptional. We hugely underuse std::error_code in STL C++ unfortunately. I am not one of those people who believes exceptions are evil, and ban them in the language as all the new system languages seem to. I also have no love for forcing everything through the return code as with C and Rust, but I do think there is a middle ground between good outcomes, bad outcomes, and exceptional outcomes which is easy to program, easy to conceptualise, and easy on the compiler. I therefore think some mongrel impure future/monad/optional type might just be the ticket. But I think I need to deliver real code used in a real world library to demonstrate its effectiveness first. If I don't persuade people of that simple effectiveness, then somebody else's solution is better.

...

I proposed to the C++ standard a function future<T>::next (bind) that takes a continuation having T as parameter (future<R>(T)), and and future<T>::catch_error that takes a as parameter a continuation that takes an errror as parameter. The proposal was not accepted.

future<T>::next( [](T){...} ) is actually pretty useful, catch_error() much less so. You should have proposed just the former. (Sean Parent's future implementation's ::then has ::next's semantics IIRC.)

I was going to have my continuations specialise on their parameter type, so a continuation might take T, error_code, exception_ptr, monad<T>, future<T> as consuming continuations. To make those non-consuming continuations simply make those a const lvalue ref. My only worry really on that feature is on compile times, so I may yet strip some of the automatedness. Also if I'm not going to regularly use a feature, then I'm removing that feature, I am aiming for a least possible implementation. We'll see how it goes. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/