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-31 10:46:45

Le 31/12/2015 10:24, Sergey Mitsyn a écrit :
> On 31.12.2015 12:00, Rob Stewart wrote:
>> On December 31, 2015 2:42:55 AM EST, Sergey Mitsyn <svm_at_[hidden]>
>> wrote:
>>>
>>> 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.
>>
>> Your point is valid except that one-type customization points are
>> likely to be provided by the library providing the type X or Y, or by
>> the library providing the customization point using a separate header
>> (opt in).
>
> But then until they don't it's still an issue, because eventually they 
> may provide, so a specialization made by a library user is a ticking 
> bomb.
>
Right. We should expect that the library document the need of such a 
customization so that the end user can know if s/he can combine it with 
other libraries.

Customization of a class X are expected to be given by the library 
providing class X, or a friend library.

I don't remember if I've already suggested to replace the deduce_xx 
customizations by a customization that depends only on the first 
parameter. I don't think this will dismiss a lot the functionality of 
the library.

Vicente
>>
>> Bold warnings in the documentation may be the only real solution to
>> the issue.
>>