Boost logo

Boost :

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at