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
> 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
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk