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

Subject: Re: [boost] [outcome v2] Please comment on new result<T, EC> reference API docs
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-06-26 07:14:11

2017-06-22 23:09 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

> > 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.
>

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;