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

Subject: Re: [boost] [outcome] expected, etc. why are these assignable
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-06-02 15:47:04

2017-06-02 17:42 GMT+02:00 Peter Dimov via Boost <boost_at_[hidden]>:

> Robert Ramey wrote:
>
> And wouldn't making these things immutable, eliminate a large part of the
>> whole controversy?
>>
>
> An immutable result/outcome would have no default constructor (because
> it's default-constructed only in cases you need to put the value into it
> later) which would eliminate the motivation for an empty state as something
> into which to default-construct... but that's only a small part of the
> whole controversy.
>
> Niall's argument for empty state does not rest entirely on default
> construction. He argues that it makes Outcome a four-state variant instead
> of a tri-state one and having the fourth state is useful in certain
> scenarios when the function that returns it has a legitimate need to report
> four states.
>
> That is, he wants to be able to express this:
>
> enum class no_difference
> {
>    _
> }
>
> expected<std::path, no_difference, std::error_code, std::exception_ptr>
>    void return_first_difference( std::path const & p1, std::path const &
> p2 )
> {
>    // ...
> }
>
> (or something along these lines, I may not have gotten the example
> entirely correct, but that's the spirit of it.)
>
> There are different legitimate ways to draw the line; you could say three
> states are it, for more use expected<>,

This is a valid point. If you need this tricky fourth state once in 1000
use cases, you can afford to use std::variant instead and leave without the
convenience of `outcome`.

Regards,
&rzej;