Re: [boost] RE [Boost-announce] [Review] Boost.Type Traits Extension by Frederic Bron

Subject: Re: [boost] RE [Boost-announce] [Review] Boost.Type Traits Extension by Frederic Bron
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2011-03-15 09:26:41

On 3/15/2011 3:00 AM, Vicente Botet wrote:
>
> Frédéric Bron wrote:
>>
>>
>>> For example:
>>> has_operator_unary_minus<  class RHS, class RET=RHS>
>>> has_operator_minus_assign<  class LHS, class RHS=LHS, class RET=LHS>
>>> This would take care of most of the normal use cases.
>>
>> I think it is best to have the default behavior to forget about the
>> return type. Why would you impose return type to be LHS?
>> It is fine for +, -, ... when RHS=LHS but when you start to deal with
>> different types, I think it just adds confusion.
>> has_operator_plus&lt;double, int&gt; would then check for a return type
>> "double" while has_operator_plus&lt;int, double&gt; for a return type int.
>> You would break the symmetry of these operators.
>>
>
> User wanting symmetry could use common_type&lt;LHS,RHS&gt; in this case. But
> using it as default is not good idea as common_type is not always defined.
> So I agree to change the default behavior to don't check.

When is common_type not defined?  I see no documentation in 
Boost.TypeTraits.CommonType mentioning it not being available for 
certain compilers...

- Jeff