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

Subject: Re: [boost] [qvm] deduce_xx traits wouldn't introduce ODR issues.
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-12-29 05:16:31

Le 27/12/2015 17:00, Emil Dotchevski a écrit :
> On Sat, Dec 26, 2015 at 5:19 PM, Rob Stewart <rob.stewart_at_[hidden]>
> 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.
>>
> It isn't exactly interoperability. The specialization in question isn't
> needed to make library X and Y compatible with each other using QVM, that's
> automatic. It only specifies the return type of operator* when multiplying
> e.g. X::matrix by Y::matrix; and it is plain wrong for X or Y to specify
> that, because the user most likely wants to get a my_matrix instead.
You should document this fact on the documentation.
> That's of course in addition to the fact that a library can't be
> responsible for ODR violations introduced by the user.
>
>
Any library that allows the user to customize its behavior must define a 
way that allows the user to avoid ODR violations, otherwise the use of 
the library by 3pp libraries don't scale.

Vicente