On Sun, May 21, 2017 at 7:35 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
Standalone ASIO is much more popular than Boost.ASIO
What do you mean by that? You can't possibly mean that standalone Boost.ASIO is more distributed by Boost -- Boost releases are everywhere!
Yes, the need to attach more information to error codes is genuine. For exceptions Boost.Exception lets us do that non-intrusively, but for error codes we do not have a similar framework.
Boost.Exception allocates memory to do that. Allocation of memory is not possible anywhere in Outcome, it ruins the point of using it for low latency C++ which is a big user base.
Control may have exited low latency contexts. High level contexts may have information relevant to an error detected and reported by low level code. There is no harm in providing the _ability_ to carry it. Secondly, the problem of memory allocation can be dealt with using alocators and shared_ptr. Generally, if a low level context has data that might be needed to handle the error, there should be a mechanism to report it, doubly so because it is tricky. By not dealing with this problem you're pushing that responsibility to the users who may need it. Retaining standalone usability of Outcome is a high priority for me. A
lot of folk from SG14 are interested in using Outcome, and I intend to submit Outcome into SG14's collection of low latency suitable libraries.
Could it be that making it part of Boost is low priority then? Or at least lower? :) The way I see it, if you want to be part of Boost, you should be a "good" member of Boost, and this does mean to *by default* include config, assert with BOOST_ASSERT, throw using BOOST_THROW_EXCEPTION, and a few other things. You can then support others users, for example let them #define OUTCOME_STANDALONE and you #ifdef out all Boost dependencies.