Boost logo

Boost :

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 02:23:56

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


ned Productions Limited Consulting

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