John Maddock wrote:
Find a way to convince Robert to allow splitting serialization.
That doesn't solve the issue I was referring to: namely library X depends on Y *only* if you're using Y anyway. Serialization being a prime example: many libraries "apparently" depend on it, but the dependency is only a true one if you're using serialization anyway.
It's a true one. These libraries include serialization headers. If serialization is not installed, these libraries break. This is not like the other false dependencies in which an optional header in X includes something in Y. (You could turn that into a 'false dependency' by moving the serialization include into an optional header, in principle.) The reason Stephen talks about splitting serialization is that adding serialization support needs only a few includes, independent of the rest of the library. If these are separated into 'serialization_core', there'll be no problem with including them. The same problem exists with range(27). Most includes only use the core part, which is a few independent headers. Also a true dependency. The only 'false' dependency that comes to mind right now is function -> typeof.