Subject: Re: [boost] [next gen future-promise] What to call the monadicreturn type?
From: Peter Dimov (lists_at_[hidden])
Date: 2015-05-28 09:25:29
Niall Douglas wrote:
> > 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
> 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.
There could be a misunderstanding. When I say that your type is
future<expected<T, error_code>>, I don't mean any specific future or
expected implementations such as std::future or boost::expected. What I mean
is a future-like type, having the interface of std/boost::future, and an
expected-like type, having (a subset of) the interface of
You could still implement your own future<> and expected<> if the existing
ones are unfit. My point is purely that these are independent concepts and
there is no real need to couple them into one type, with a hardcoded
error_code to boot.
So far, you've stated that you like that your type is constructible from T,
error_code or exception_ptr. I suppose a future<expected<T, error_code>> may
not be as convenient. Are there other ways in which the interface of
future<expected<T, error_code>> is deficient?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk