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

On Wed, Jun 21, 2017 at 7:23 PM, Niall Douglas via Boost < boost@lists.boost.org> wrote:

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 (an optional) or result (something like a glorified pair.)

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 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 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 in practice. Either you're using result to return Success + Status

If I wanted to return Sucess + Status, I would return pair as the value (as opposed to the error) from a given function.