Re: [boost] [outcome] expected, etc. why are these assignable

Subject: Re: [boost] [outcome] expected, etc. why are these assignable
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2017-06-02 16:54:04

On 2 June 2017 at 18:43, Peter Dimov via Boost <boost_at_[hidden]>
wrote:

> Richard Hodges wrote:
>
>> Forgive me chiming in late, but what is the semantic difference between:
>>
> There are various ways to represent the same four-state variant
> syntactically, and the main difference is in, well, syntax, when referring
> to it. You could, for example, use
>
>    outcome<variant<std::path, no_difference>>
>
> (assuming a never-empty tri-state outcome)
>
> or
>
>    outcome<optional<std::path>>
>
> Completely agree that in this case optional<std::path> is equivalent to
variant<path, no_difference>. My concern is around allowing more than two
main code paths when testing the outcome. It seems to me that all outcomes
will either 'pass' in some way or 'fail' in some way. These are the main
concerns are they not? By all means the happy path might specialise
happiness, but it's still happiness, right?

we could argue that some process might partially complete, and that could
be captured with:

outcome<variant<result, partial_result_try_again>>

A partial result is not a failure. Isn't the purpose of outcome to simply
offer a non-throwing alternative to exceptions without requiring in/out
variables? Or is there some wider use case I haven't thought of? If so,
couldn't that be trivially composed as above?

>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman
> /listinfo.cgi/boost
>