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: Avi Kivity (avi_at_[hidden])
Date: 2015-05-25 11:33:06

On 05/25/2015 05:57 PM, Niall Douglas wrote:
> 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.

As I mentioned, in this case the user can use expected<> or similar 
themselves.  Otherwise, what's the type of error_code? There could be an 
infinite amount of error_code types to choose from (starting with simple 
'enum class'es and continuing with error codes that include more 
information about the error (nonscalar objects).

> 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.

I'm not sure how the default constructor of future<> and the move 
constructor of T are related.

I'm not even sure why future<> would require a default constructor.  
Seastar's doesn't have one.

>
>>> ... 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.
>
>

I'm looking forward to it!  I've been bitten by the same compile time 
explosion problems and I'm curious to see how you solved them.