Niall Douglas wrote:
The code has a "boost-lite" submodule. Is that part of the review?
In terms of public API, only the single part of boost-lite's API exposed in Outcome's public API which is boost-lite::tribool, which I exposed specially into the reference docs at https://ned14.github.io/boost.outcome/group__tribool.html
(Outcome provides ternary based logic as an extension. If the peer review desires, we can fake hide tribool into namespace boost::outcome)
Boost-lite provides the cmake based build, config, test, Boost.Test alternative, install, partial preprocess single header include generation and much of the internal implemention classes used by Outcome. However if accepted then Outcome would gain a Boost.Build veneer and be auto generated by script from the standalone Outcome same as Boost.ASIO is, and so I figure none of that is in scope for this review.
This doesn't exactly inspire confidence. When a library enters Boost and is distributed in Boost releases, there's no longer any point of it duplicating Boost functionality under the hood (without a very good reason); while not requiring Boost is understandable for standalone use, in a Boost release Boost is by definition already available. In addition,
then Outcome would [...] be auto generated by script from the standalone Outcome same as Boost.ASIO is
carries the unfortunate implication that Outcome in Boost may be, similarly to Boost.ASIO, a second-class citizen that may lag behind the "real" Outcome where the real development occurs. And finally,
then Outcome would gain a Boost.Build veneer...
libraries are much easier to review if they are already in their final Boost form, ready to be copied into $BOOST_ROOT/libs/$library. It's understandable that people don't want to invest into that final step until the library is accepted... but it should also be understandable that going that extra mile is a sign of commitment that speaks positively about the author and can therefore tilt reviewers toward acceptance.