Rob Stewart wrote:
On December 26, 2015 4:54:19 AM EST, Rainer Deyke
wrote: I think, rather than X and Y providing conflicting definitions, the problem is that abc provides a specialization to allow interoperability with def, and def does the same for abc. Using the two libraries, in that case, always creates a conflict. This implies a circular dependency between abc and def. If those
On 25.12.2015 13:03, Rob Stewart wrote: libraries are that tightly coupled, surely they can work out this conflict between themselves? It implies no such thing. It implies that each library provider chose, independently, to offer interoperability with the other using QVM.
This would be problematic if interoperability was mandatory in both libraries, i.e. always required. A root cause is that a library may specialize traits for a type from different library. With traits taking two types it's slightly more probable to have a conflict. However with single-type traits this could be the case too. If we assume that both libraries requires interoperability, that they depend on each other, that the developers doesn't communicate with each other, they add QVM dependency at the same time and don't test with development version of the other library then even single-type traits can be a problem. The problem doesn't exist if one of these conditions is not met, e.g. each library specialize traits only for types from this library, makes the interoperability optional, developers communicate with each other, etc. Furthermore the specialization of those deduce_xx traits is not required so I think that in practice it will not be specialized in a great majority of cases. Maybe would it be sufficient to simply describe the potential problems in the documentation? Regards, Adam