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

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 
> 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 <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 
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