On 05/07/2020 19:41, Emil Dotchevski via Boost wrote:
On exception_ptr, my original thinking (more than 15 years ago) was this: the parts of Boost Exception that could be used to call boost::throw_exception should work under BOOST_NO_EXCEPTIONS, but since exceptions can't be thrown, there's no reason why anyone would want to hold a pointer to one.
What about make_exception_ptr()? There is a long story behind that function and whether it ought to work with exceptions globally disabled or not. Basically, many years ago, I reported to those STL implementations which were still implementing it as a throw...catch, instead of direct construction, benchmarks showing the hideous performance of not using direct construction. The maintainers of said STL implementations did not think it important enough to fix, but to my best knowledge, they have all since fixed that. This reduces the cost of std::make_exception_ptr() from 30k CPU cycles to about 3k CPU cycles, big gain if you do a lot of those. I'd pitch the same thing to you: thanks to make_exception_ptr(), exception_ptr is quite useful with exceptions globally disabled.
You're the first person to ever raise a need for a outcome/boost_result.hpp which does not include Boost.Exception.
From my point of view, I was compiling an example that used outcome::result and was surprised that it didn't work under BOOST_NO_EXCEPTIONS. Even if we change boost::exception_ptr to work under BOOST_NO_EXCEPTONS, should outcome::result be coupled with it?
I propose two paths forward: 1. Boost.Exception gains an exception_ptr which works fine with BOOST_NO_EXCEPTIONS. 2. Boost.Outcome disables use of boost::exception_ptr when BOOST_NO_EXCEPTIONS is enabled. I'm easy with either choice. But I think the former "nicer". Also, for the record, about 70% of my users use result<> with error or enum codes, perhaps 20% use exception_ptr, the remaining 10% use a custom type. Those who use exception_ptr are quite vocal, however. BTW if you are thinking of Boost.Exception improvements, that report going around for why Boost libraries cannot be epoch-ised, it said the only blocker for Outcome was its dependency on Exception. So, if Exception could be epoch-ised, so could Outcome. Me personally I give that whole proposal a very low priority, but while we're talking etc etc Niall