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<T, error_code> into future<T> is the correct decision. If people want to abide to a programming style based on expected<T, error_code>, let them just use future<expected<T, error_code>>. No need to couple independent components. I also disagree with the implicit expectation that a programming style based on expected<T, error_code> 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.