Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at