Re: [boost] [review] Review of Outcome (starts Fri-19-May)

Niall Douglas wrote:

And finally, I do intend to keep Outcome working completely independent of Boost. The vast majority of my user base explicitly do not want a Boost dependency.

The vast majority of your user base may change if your library is accepted. It almost certainly will. Not wanting to depend on Boost is understandable. Our common infrastructure however is not just a whim of ours, it's a service to Boost users. Going through BOOST_ASSERT and BOOST_THROW_EXCEPTION instead of rolling your own is more convenient for people who have already configured BOOST_ASSERT and BOOST_THROW_EXCEPTION to do what they want them to do and would rather not repeat that exercise for every new library, however wonderful. Similarly, once we get the kinks out of Boost.Stacktrace, it might be better to use that instead of #including . All that's not strictly required for acceptance, in principle; neither is using Boost.Config instead of rolling your own. And yet. Regarding the ring buffer, I agree that it adds value. But it also adds complexity. There's an argument to be made for result/outcome classes that simply store std::error_code without all the bells and whistles, and provide an optional hook to which the user can attach the ring buffer if needed. You already have a macro-based hook for that, although I'm thinking more of a callback. Finally, you don't even need to macro-bind to std::error_code. Inspired by Outcome, I wrote a pull request for Boost.System which makes the Boost error_category, error_code and error_condition convertible to the standard ones, so you can just store std::error_code and be done with it. https://github.com/boostorg/system/pull/16