Subject: Re: [boost] [next gen future-promise] What to call the monadic return type?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-28 09:05:51
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<T, variant<error_code, exception_ptr>>
> > 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<expected<T, error_code>>, 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/