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-22 07:53:44

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

> On 22/06/2017 02:08, Peter Dimov via Boost wrote:
> > Niall Douglas wrote:
> >> The idea, since we no longer have variant storage, is to see if we'd
> >> like to implement
> >>
> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0262r0.html
> >> (except with the parameter order reversed).
> >
> > I'm not particularly enthusiastic about status_value (and the argument
> > given in the paper is unconvincing.) Neither am I thrilled by the idea
> > of result<R, void> (an optional) or result<void, void> (something like a
> > glorified pair<bool, bool>.)
>
> I've fixed the problems you raised at
> https://dedi4.nedprod.com/static/result-v2/doc_result.html and moved the
> implementation stuff into a impl namespace so standardese will still
> show the docs for the composited types, but not be usable by end users.
>
> > result<T, EC> in its original form represented a very clear concept: the
> > type of a function that must either return a value, or a reason for the
> > lack of value. All of the above do not fit this concept and to me ring
> > hollow.
>
> Andrzej feels similarly to you.
>
> But I don't think things are as bad as both of you feel. In v2 result<T,
> EC> you now can have:
>
> 1. Successful: T
>
> 2. Failure: EC
>
> 3. Successful + Status: T + EC
>
> The reason I don't think this is a problem is because you can't
> accidentally return a wrong result<T, EC> in practice. Either you're
> using result to return Success + Status, or you're using result to
> return Success | Failure. It is very hard to accidentally write code
> which does the wrong thing here, almost certainly the type system would
> refuse to compile incorrect code.
>

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.

Regards,
&rzej;