Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-20 22:47:20
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
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 <windows.h>.
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk