On May 25, 2015 5:37:26 AM EDT, Niall Douglas
My final design is therefore ridiculously simple: a future<T> can return only these options:
* 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; } test().get();
... turns into a "mov $5, %eax", so future<T> is now also a lightweight monadic return transport capable of being directly constructed.
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 reading https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a8.DESIGN:Strongl....
Make the examples in that correct WRT shared_ptr. As written, the shared_ptrs will delete file handles rather than close them.
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>.
The idea has merit, but I have some concerns. The best practice you've linked states that there are problems with Boost.Threads' expected type, but you only mention compile times specifically. I'd like to better understand why expected cannot be improved for your case. That is, can't expected be specialized to be lighter for cases like yours? Put another way, I'd rather one type be smart enough to handle common use cases with aplomb than to have many specialized types. I realize that doesn't solve your immediate need, but you have your own namespace so you can just create your own "expected" type until the other is improved. Then, if improvement isn't possible, you can explore another name for your expected type. ___ Rob (Sent from my portable computation engine)