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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-06-22 21:09:17

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