You could say "if you do not like the state `has both value and error`, then don't create it", and this could be considered acceptable, but now that you have said you intend to change "error" into "status", you are affecting even this conservative usage.
In the paper by Laurence Crowl, in the example with queue status:
``` Value queue::value_pop(); queue_op_status queue::wait_pop(Value&); ```
what he is describing is: pair<optional<T>, status>
Whereas what you provide (if I got it correctly) is: pair<optional<T>, optional<status>>
Which means I can get a value with no status. This still does not implement P0262.
In response to yours and Peter's concerns, I've now tightened the semantics considerably. For result<T, S> you now may do: 1. Construct with a T. .value() returns that T. .status() throws bad_result_access. There is no .error(). 2. Construct with a T and an S. .value() returns that T, .status() returns that S. There is no .error(). And that's it. If trait::enable_errored_result_creation<S> is true however, you get this instead: 1. Construct with a T. .value() returns that T. .error() throws bad_result_access. There is no .status(). 2. Construct with an S. .value() throws that S according to policy. .error() returns that S. There is no .status(). So result<T, S> is either wearing a "status hat", or it is wearing a "failure hat". It cannot be both. The only remaining objection now is that result<...> is named the same yet has different semantics depending on its S type. Yet error_code is also a status, it's just a *negative* status rather than a *positive* status. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/