Subject: Re: [boost] [next gen future-promise] What to call the monadic returntype?
From: Peter Dimov (lists_at_[hidden])
Date: 2015-05-26 07:07:16
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk