John Maddock wrote:
The reason Stephen talks about splitting serialization is that adding serialization support needs only a few includes, independent of the rest of the library.
That may well be true, however, if the answer to every issue is "split it up" then something else is very wrong.
I agree. I advocate against splitting and I advocate for merging some core modules. Splitting is the answer to *this* issue.
It makes no sense to me to have multiple "micro-libraries" scattered over multiple repositories: no one will ever be able to find anything!
As an aside: Multiprecision supports serialization, but without including any of that library's headers - rather it just provides the interface that the Serialization lib expects. While the magic-macros that Serialization provides to simplify providing support are useful for quick and dirty prototyping of code, I suspect that many (most, all?) of these dependencies could be removed by writing real code instead. So perhaps this is more a question of documentation in the Serialization lib, and officially-blessing interoperability via code, as well as the Serialization-provided macros?
Or splitting off a proper interface for those libraries to implement.
None of which is relevant to the common_type issue BTW.
Right. This started because I pointed out that serialization is not a general 'library X library Y' problem which you suggested in a previous email. Thanks, Steve.