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

Subject: Re: [boost] [outcome] expected, etc. why are these assignable
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-02 21:58:26

On 02/06/2017 16:42, Peter Dimov via Boost wrote:
> Robert Ramey wrote:
> 
> 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.

Nearly correct, but not quite.

My argument in favour of an emoty state is because the implementation
will implement an empty state internally anyway, so either you expose
that publicly, or you don't. It's no difference for the implementation.

You then list the use cases for a formal public empty state, and on
balance I came out in favour. During the review quite a few people came
to the same conclusion: on balance, it's better than the alternatives.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/