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-26 07:21:57

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

> > So result<T, S> is either wearing a "status hat", or it is wearing a
> > "failure hat". It cannot be both.
> >
> > The only remaining objection now is that result<...> is named the same
> > yet has different semantics depending on its S type. Yet error_code is
> > also a status, it's just a *negative* status rather than a *positive*
> > status.
>
> I've pushed clarifying reference API docs regarding this trait
> separation of positive versus negative status types to
> https://dedi4.nedprod.com/static/result-v2/doc_result.html.
>
> I appreciate that this change is controversial. However, I am also
> minded that there is no point in Outcome v2 covering the identical
> ground as Expected, just less well. Outcome ought to be isomorphic to
> Expected, be strong at the areas Expected is weak at and so on.
>

It seems to me you do not appreciate the value of Outcome v1. The ground is
not identical to Expected. You said you refused to implement some parts of
Expected because of practical considerations -- I was convinced by that as
this indicated that you have tested it in practice both as a user and as an
implementer.

The significant value of Outcome v1 is that you have used it already in two
big libraries. It has been tested in the field. Hence, probably, the
practical solutions like the `TRY` operation. With this library comes a big
practical experience of the author, the micro optimizations, usage idioms.

Now with Outcome v2, you seem to loose this advantage; you are implementing
a theoretical feature, which have never been tested in practice, of which
it is not clear what users expect, and if it even be used.

Regards,
&rzej;