Le 14/06/2017 à 00:05, Emil Dotchevski via Boost a écrit :
On Tue, Jun 13, 2017 at 1:01 PM, Bjorn Reese via Boost < boost@lists.boost.org> wrote:
On 06/13/2017 12:38 AM, Emil Dotchevski via Boost wrote:
I'll spell it out: Noexcept + optional<> ≈ Outcome That approximation only holds for function-calling scenarios. As I pointed out in my review, there are other use cases for Outcome. Noexcept is a bad match for these use cases, because it transports errors "out-of-band" like errno.
One use case is to pass a value-or-error between threads. We already have one outcome-like feature for this: promise-future. If we want to use a different mechanism to pass the value-or-error between threads, then Outcome offers a natural solution.
Another use case is to pass a value-or-error via a queue. The queue may contain several outstanding errors. In the case of Outcome, we simply push the value-or-error directly to the queue.
Yes, though I consider this a separate issue. One is, what's the best way to transport errors across error-neutral functions within a single thread, the other is what to do when, somewhere way up the stack, we get a successful value or an error. At that point it's trivial to build a variant
or equivalent, you don't need a lib for that.
+1 Vicente