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
Whereas what you provide (if I got it correctly) is:
pair
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 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 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/
