On 3/02/2023 10:57, Andrzej Krzemienski wrote:
We have (I think a still unresolved issue) of Boost-serializing Boost.Optional. Should the code responsible for the serialization of Boost.Optional be part of Boost.Serialization or Boost.Optional? But we will certainly not solve it by introducing yet another library. There are other ways to solve it, say, through optional headers.
I think the two schools of thought on that are: 1. Serialization came first and so Optional should take it into account in its implementation. 2. Optional is more fundamental than Serialization, and you're more likely to use optionals than serialization, so the latter should have the supporting code. I personally find the second argument more compelling (although the waters are muddied by there now being a std::optional too, increasing the chance you might want serialization without caring about boost::optional), but that only solves the problem of which repository the bulk of code should belong to. Unfortunately in C++ there's no way to say "if these two otherwise unrelated headers were included then also include this", short of order-sensitive preprocessor checks. This then I think leads to only three reasonable solutions: 1. The user has to know that the integration exists and explicitly #include an additional header file (e.g. boost/serialization/optional.hpp) when they're using both together. 2. *Both* libraries need to detect the other and include the integration header from their top-level wrapper regardless of the original include order. So if the user happens to include both libraries "in general" then they get the integration automatically. 3. One library decides that the other is sufficiently "vocabulary" and/or small enough to always be loaded if the first is, and just unconditionally includes it (from the perspective of the "whole library" header, at least). For this particular case, Boost appears to have chosen #1 currently, and doesn't implement #2 or #3. These are not mutually exclusive. #2 is the most user-friendly option (#1 is less discoverable), but it's not readily extensible for detecting if std types are included, or for third-party library types unaware of Boost, making it rather awkward in practice for anything non-Boost. I'm not entirely sure how this all applies to the Buffers/Asio situation. Logically, Buffers would be more fundamental than Asio, so it would make sense for Asio to be modified to use/be compatible with Buffers (rather than the reverse, as currently seems to be proposed), though I'm not sure how well that would catch on since Asio will likely want to retain its own buffer implementations for standalone use at least.