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

Subject: Re: [boost] [outcome] expected, etc. why are these assignable
From: Peter Dimov (lists_at_[hidden])
Date: 2017-06-02 15:42:09

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<>, or you could say, four states cover 
the majority of the legitimate cases, so let's have that.