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-30 14:39:33

2015-12-29 1:30 GMT+01:00 Vicente J. Botet Escriba <vicente.botet_at_[hidden]
>:

> Le 23/12/2015 23:44, Adam Wulkiewicz a écrit :
>
>>
>> AFAIU the problem might occur if there were e.g. two libraries (abc and
>> def) providing their own matrix representations (e.g. abc::mat4x4 and
>> def::mat4x4). Then we'd have two other libraries (X and Y) both using those
>> two matrix types together with QVM. So both X and Y libraries would have to
>> specialize QVM traits for abc::mat4x4 and def::mat4x4. Then, if both X and
>> Y libraries were included in a program there would be problems since the
>> specializations of QVM traits would be duplicated. I'm not sure if we could
>> do anything about it because similar problem would occur every time when
>> any traits was required by any library. So AFAIU this is what Emil is
>> saying.
>>
>> Or are deduce_xx traits somehow different than other QVM traits?
>>
>> Vincente is this what you had in mind or was it a different issue?
>>
>>
>> Hi,
>
> yes, this is exactly the case.

Emil, do you think that the deduce_xx traits are something that is crucial
for the library? Or could it be e.g. hidden in the details?

I'm asking because in general in QVM return types are hidden from the user
and only if the user wants to do something special he must e.g. overload an
operator or a function. Why not rely on this mechanism also in this case?

Furthermore AFAIU two-argument deduce_xx are only used in operations taking
operands of the same kind and returning a result of the same kind as the
operands, where "kind" means "type adapted to the same concept", e.g.
matrix from two matrices, vector from two vectors, etc. So while the
coverage is quite good operations taking various kinds of arguments like
e.g. a vector and a scalar generating a matrix are not covered. In such
cases the library can return any type, right?

So I'm wondering, would it be a good idea to simply pick some good default
and simply rely on overloading if something fancy was needed?
The default could be the same type for two operands of the same type, and
something unspecified in other cases, so the same as it is now.

Regards,
Adam