Re: [boost] [outcome] How to drop the formal empty state

Subject: Re: [boost] [outcome] How to drop the formal empty state
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-25 14:59:48

Niall Douglas wrote:
> > 1b. make them default-construct to `make_error_code( 
> > outcome::errc::uninitialized_result )`.
>
> I am not keen on magic constants in an errored state. I am also not keen 
> on overloading the errored state with alternative meaning. The errored 
> state is for indicating an end user operation failed somehow, not for 
> detecting logic errors in user code.
>
> This is precisely why I added a formal empty state, and default 
> initialised to that. Because it causes behaviour different to valued or 
> errored, it **very** effectively traps logic errors during code 
> development. On **many** occasions it has successfully illuminated poorly 
> thought through code that I have written by bringing to my attention - 
> early and very obviously - that someone was very wrong. I am absolutely 
> convinced it is a great design choice.

OK, fair enough. I don't think that the benefits of having a singular state 
outweigh its disadvantages, but to each his own.

> I'd therefore be happier with default construction giving uninitialised 
> contents, or a default constructed T or E. No overloading state of E.

result and outcome have no E. I'm not talking about E or expected<T, E> 
here. I'm talking specifically about result<T> and outcome<T>. That is, I'm 
trying to answer the question "Under the assumption that expected<T, E> 
doesn't exist, what should the default constructor of result<T> do?"

Default constructing to an std::error_code of 0 is kind of stupid because 
"The operation failed: The operation succeeded", although one might, I 
suppose, make an argument in favor of constructing into a stupid state 
precisely because it's stupid.