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

Subject: Re: [boost] [qvm] deduce_xx traits wouldn't introduce ODR issues.
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2015-12-31 14:24:03

"Need" is too strong, specifying the return type for binary operations is
optional. The deduction templates for binary operations must use two
parameters because they define the return type specifically for a given
pair of argument types.

On Thursday, December 31, 2015, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> 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.
>>>
>>>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode