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

Subject: Re: [boost] [next gen future-promise] What to call the monadic return type?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-25 10:57:30

On 25 May 2015 at 15:44, Avi Kivity wrote:

> I believe error_code is unneeded.  Exceptions are expected to be slow.  
> If you want another type of variant return, let the user encapsulate it 
> in T (could be optional<T>, or expected<T, E>, or whatever).

Please read the rationale at 
https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a8.DESIGN:S
tronglyconsiderusingconstexprsemanticwrappertransporttypestoreturnstat
esfromfunctions as was requested.

In particular, error_code is fast, and unexpected returns are not 
exceptional and must be as fast as expected returns.

Also, any monadic transport would default construct to an unexpected 
state of a null error_code in fact, which is constexpr. This lets one 
work around a number of exception safety irritations where move 
constructor of T is not noexcept more easily.

> > ... turns into a "mov $5, %eax", so future<T> is now also a
> > lightweight monadic return transport capable of being directly
> > constructed.
> 
> Can you post the code?  I'd be very interested in comparing it with 
> seastar's non-allocating futures.

I may do so once I've got the functioning constexpr reduction being 
unit tested per commit.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/