Re: [boost] [outcome v2] Please comment on new result<T, EC> reference API docs

2017-06-22 23:09 GMT+02:00 Niall Douglas via Boost :

...

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.

If you are determined to go this way, why not offer two separate templates: `annotated` and `result`. The former for the "status" functionality, the latter for the Outcome-v1-like "either T or error", and have them just share the same implementation. Since they have different semantics and member functions why have them share the same name? Regards, &rzej;