On Mon, Feb 6, 2023 at 2:43 PM Gavin Lambert via Boost
Perhaps, though as I said I find the "optional is more fundamental" argument more compelling, so by that logic the compatibility code should be in serialization and not optional.
I just want to underscore that the question of "where does optional go" is completely orthogonal to this proposed Boost.Buffers library, and the buffers::source and buffers::sink interfaces in particular. My proposed library has nothing to do with serialization and everything to do with providing buffer-oriented interfaces. In fact, buffers::source is more fundamental than serialization. Boost.Serialization sits between buffers::source and the algorithm for serialization of an optional. This diagram shows the relationship: { host } <---> Boost.Buffers <---> Boost.Serialization <---> { optional } In this diagram "host" is the host program or library which is implemented in terms of Boost.Buffer's abstract interfaces (buffers::source for the case of using Boost.Serialization). As seen in the diagram, the question of where the serialization spec for "optional" goes, is unrelated to Boost.Buffers. Another way to think of it is like this. If Boost.Serialization implements the buffers::source interface, then any host which uses Boost.Buffers will be able to make use of types archived through Boost.Serialization. I'm not saying whether this is particularly useful or not as that would depend on the specific use-case. For the upcoming Boost.Http.Proto library, this means that anything which defines a serialization for Boost.Serialization could be attached as the body of an HTTP message. The diagram for Boost.JSON looks different: { host } <---> Boost.Buffers <---> Boost.JSON Here, if Boost.JSON wraps its existing streaming serializer for the buffers::source interface then any Boost.Buffers-enabled host can make use of JSON sources without depending on the Boost.JSON library. There's a network effect at play; every library that enables Boost.Buffers geometrically increases the utility of every other library that uses Boost.Buffers. Furthermore, this scales to any number of libraries and resolves the question of where the buffers::sink (or buffers::source) algorithm goes. It goes in the library which already implements a buffer-oriented data type. This includes but is not limited to: * JSON * XML * Boost.Serialization archives * Mustache templates and output Thanks