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