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
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
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 http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/