Subject: Re: [boost] [outcome v2] Please comment on new result<T, EC> reference API docs
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2017-06-22 19:01:40
On Wed, Jun 21, 2017 at 7:23 PM, Niall Douglas via Boost <
> 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
If I wanted to return Sucess + Status, I would return pair<Success,Status>
as the value (as opposed to the error) from a given function.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk