Niall Douglas wrote:
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)
I don't think that inlining expected into future<T> is the
correct decision. If people want to abide to a programming style based on
expected, let them just use future>.
No need to couple independent components.
I also disagree with the implicit expectation that a programming style based
on expected will take the world by storm. It won't.
Exceptions are much more convenient and make for clearer code. C++
programmers are not Haskell programmers and don't want to be; they don't use
monads and do-statements. There is no need.
