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

2017-06-23 0:24 GMT+02:00 Niall Douglas via Boost :

...

So result 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;