$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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.