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

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