[boost] [review] outcome

Subject: [boost] [review] outcome
From: Vinícius dos Santos Oliveira (vini.ipsmaker_at_[hidden])
Date: 2018-01-26 11:00:08

That is my review of Boost.Outcome.

What is your evaluation of the design?

Niall did an excellent job weighting trade-offs and coming up with such an
pleasant and convenient interface that not only is convenient, but it has
customization points in the appropriate layers to fit not-close-to-trivial
use cases.

I've read the changes between v1 and v2 and I agree with the rejection
reasons of previous version (the v1's null state specially made little
sense at all). Version 2 is a very realistic and solid project.

It might seem teasing to just port abstractions from functional languages
to C++ (e.g. Expected), but C++ is its own beast and we cannot just ignore
some features that we have been dragging all along like exceptions if we
expect to have any realistic usage in the real world. Niall's intuition on
how to weigh trade-offs was outstanding and just proves his C++ familiarity
and expertise. In special, default actions/behaviours could only be defined
by intuition of some experienced programmer and not "mathematically".

What is your evaluation of the implementation?

I did not check the implementation.

What is your evaluation of the documentation?

Very well written. The tutorials are excellent-quality. The use cases and
examples were chosen in such a way that it was intuitive to understand
why/when Boost.Outcome and not Expected. I noted a few small problems, but
they were reported already.

The comments on the example codes were seemingly foreseeing ahead enough
about "pumping doubts" so that my mind would calm down and actually pay
attention to the documentation instead doing mind exercises trying to guess
the non-point of the example. I wish I had this skill.

What is your evaluation of the potential usefulness of the library?

Very useful. Error handling is a core constant in any programming activity.
Introduction of Boost.Outcome could potentially remove duplication of
throwing and non-throwing APIs. I personally prefer Expected with its
monadic operations, but it is unrealistic to ignore exceptions in many code
bases and I'd certainly go for Boost.Outcome in these cases.

Did you try to use the library? With what compiler? Did you have any
problems?

Yes. The one-header version of the library made testing incredibly easy. No
problems.

Clang 5.0.1.

How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?

A few hours over a span of a few days. I've tried to examine documentation
carefully and end up sending a pull request and a few comments to ask for
further changes. I've read all threads that came up during review.

I also tested the library when in doubt.

Are you knowledgeable about the problem domain?

I worked for more than one year under contract using the Rust programming
language and Boost.Outcome is pretty much the error system we have in Rust
(with some C++-ification and an experienced C++ unique programmer
"intuition" to also cover exceptions... and w/o monad ops, of course).

Do you think the library should be accepted as a Boost library?

Yes.

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/