Re: [boost] [review] Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-05-16 00:54:22

On 16/05/2017 11:47, Peter Dimov wrote:
> Gavin Lambert wrote:
>
>> Maybe I'm missing some context, but unless T is void, making a void
>> get() method seems very peculiar to me.  Logically a get method should
>> actually get something.
>
> get() is not a very good name, it's more like ensure(), and the intended
> use is in the transition from an outcome<>-using layer to a throwing layer:
>
> T f() // throws
> {
>    outcome<X> o1 = f1_impl(); // doesn't throw
>    o1.ensure(); // ensure we have a value
>
>    outcoume<Y> o2 = f2_impl();
>    o2.ensure();
>
>    return { *o1, *o2 };
> }
>
> The reference access paradigm implies that we want to keep the values in
> the outcomes, so there's no need to actually extract them, we can use
> them in-place.
>
> In contrast, the value return paradigm implies that in this scenario we
> want to extract the values from the outcomes and throw the outcomes away:
>
> T f()
> {
>    X x = f1_impl().value();
>    Y y = f2_impl().value();
>
>    return { x, y };
> }

Surely this must also throw if f1_impl() can produce an error outcome 
and thus might not contain an X?  I don't see the distinction.

(Use of outcome<X> above implies that X is not itself an error-capable 
type.)