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/