On 29.12.2015 22:54, Rob Stewart wrote:
What if the two libraries that specialize the return type are not related to the two that provide X and Y, but are, say, internal libraries used by different teams? If a third team decides to use the first two teams' libraries together, the problem arises again. The specializations would be reasonable for the first two teams. Only the third team has a problem and you can easily imagine that no one from the first two teams would think of the potential problem to warn the third team.
Correct me if I'm wrong, but it to me seems that the root of evil here is a specialization by third party library, by which I mean the case when template from library X is specialized with type(s) exclusively from library (libraries) Y (Y might be the same as X) by library Z (which is neither X nor Y, third party). If it's true, an ODR would be caused for a user even if _unary_ deduce_m (or any other deduce_X) will be specialized by two unrelated third party libraries A and B imported by user. Adding an extra formal type parameter to the template(s) for tag type from library Z would make it safe, but in this case that's pointless as QVM's template machinery would not know which tag to use. If this is a flaw, then many things are also flawed - e.g. overloads by third party too. Also, adaptation of any set of types to any concept by third party. E.g., std::vector is adopted to BGL with boost/graph/vector_as_graph.hpp, but any third party library shall not adopt boost::container::vector; this can only be done by one team. For large teams it seems unmanageable. The question is does it mean that libraries that provide templates for specialization (or overloading) are undesirable? Or can a specialization be just limited in such a way that no third party library (as defined above) shall specialize it? I.e., libraries - only for their own types, users - for anything, given they can find a way to manage this in large projects.