Re: [boost] [qvm] deduce_xx traits wouldn't introduce ODR issues.

Subject: Re: [boost] [qvm] deduce_xx traits wouldn't introduce ODR issues.
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2015-12-27 11:15:52

Rob Stewart wrote:
> On December 26, 2015 4:54:19 AM EST, Rainer Deyke <rainerd_at_[hidden]> wrote:
>> On 25.12.2015 13:03, Rob Stewart 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
>> 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