Boost logo

Boost :

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

Dear list,

As AFIO looks likely to be finally getting a community review soon,
I've made a start on a final non-allocating constexpr-collapsing next
generation future-promise such that the AFIO you review is "API
final". You may remember my experimentations on those from:

Essentially the win is that future-promise generates no code at all
on recent C++ 11 compilers unless it has to [1], and when it does it
generates an optimally minimal set with no memory allocation unless T
does so. This should make these future-promises several orders of
magnitude faster than the current ones in the C++ standard and solve
their scalability problems for use with things like ASIO. They also
have major wins for resumable functions which currently always
construct a promise every resumable function entry - these next gen
future-promises should completely vanish if the resumable function
never suspends, saving a few hundred cycles each call.

Anyway, my earlier experiments were all very promising, but they all
had one big problem: the effect on compile time. My final design is
therefore ridiculously simple: a future<T> can return only these

* A T.
* An error_code (i.e. non-type erased error, optimally lightweight)
* An exception_ptr (i.e. type erased exception type, allocates
memory, you should avoid this if you want performance)

In other words, it's a fixed function monad where the expected return
is T, and the unexpected return can be either exception_ptr or
error_code. The next gen future provides Haskell type monadic
operations similar to Boost.Thread + Boost.Expected, and thanks to
the constexpr collapse this:

future<int> test() {
  future<int> f(5);
  return f;

... turns into a "mov $5, %eax", so future<T> is now also a
lightweight monadic return transport capable of being directly

In case you might want to know why a monadic return transport might
be so useful as to be a whole new design idiom for C++ 11, try

However, future<T> doesn't seem named very "monadic", so I am
inclined to turn future<T> into a subclass of a type better named.
Options are:

* result<T>
* maybe<T>

Or anything else you guys can think of? future<T> is then a very
simple subclass of the monadic implementation type, and is simply
some type sugar for promise<T> to use to construct a future<T>.

Let the bike shedding begin! And my thanks in advance.


[1]: Compiler optimiser bugs notwithstanding. Currently only very
recent GCCs get this pattern right. clang isn't bad and spills a
dozen or so completely unnecessary opcodes, and I'll follow up with
Chandler with some bug reports to get clang fixed. Poor old MSVC
spits out about 3000 lines of assembler, it can't do constexpr
folding at all yet.

ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at