On Thu, Feb 2, 2023 at 2:47 PM Gavin Lambert via 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.
Well as I mentioned in my previous message, I think that serialization is a different thing from where Buffers would be applicable. As an interesting note. Boost.JSON handles conversion of OptionalLike types to JSON when performing json::value_from and when serializing (soon). We did this not by depending on Boost.Optional but rather, defining a concept for all OptionalLike types. Generally speaking I think if a library wants to support types that match certain generic concepts, then the place for that support goes into the library itself. I would be in favor of a Boost library which offered metafunctions for identifying types which match certain models such as OptionalLike, MapLike, StringLike (e.g convertibility to string_view), TupleLike, VariantLike and such. JSON could use that and perhaps Serialization. It might be worth exploring. I have designed Boost.Buffers to work with Asio (but without requiring Asio) to make it palatable to use. Asio changing is extremely unlikely so the burden is on Buffers to be interoperable. On a separate note all of this talk about headers only working when other headers are "present" or anything like that, makes me uncomfortable. I like it when a build always produces one version of the library no matter what else is installed or what macros are set. I've tried to get fancy with includes and I always regretted it. Thanks