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