Re: [boost] review request: addition to type_traits library ofis_less_comparable<T, U> and others

Subject: Re: [boost] review request: addition to type_traits library ofis_less_comparable<T, U> and others
From: John Maddock (john_at_[hidden])
Date: 2009-12-07 12:24:31

>> has_operator_less<T, R = bool>
>
> Maybe should be has_operator_less< T, U = T, R = bool > ?  (one step
> further than frederic's suggestion, and in line with your
> has_operator_plus suggestions below)
>
>> So how about: has_operator_plus<T, U = T, R = dont_care> ?
>>
>> Hard to decide what R should default to in this case, I'm tempted by the
>> "permissive" case of dont_care because it will do the right thing in
>> more mixed arithmetic cases, but the alternative would be to default R
>> to T I guess.
>
> Default R = common_type<T,U>::type (the common_type from another thread) ?

Doesn't this put the cart before the horse?

If there is no common type because the no such operator is defined won't we 
get a compile error rather than the false result that we want?  Plus 
common_type would rely on typeof-emulation and type registration, which 
rather negates the point of defining the type_traits class?

> And (somewhat off-topic) I think the default common_type should *not*
> use decltype (i.e., Boost.Typeof) if not available, which would limit
> common_type<T,U>::type to be either T or U most of the time, unless
> specialized.

Ah I see, it would have to in order to work in this case, but might give the 
wrong answer in other cases?

> Also, why couldn't void take the place of dont_care ?

Depends on whether we want to differentiate between operators that return 
void, and the genuine "don't care" case?  But... I suspect that detecting a 
void return isn't possible anyway, so yes maybe that would work.

Cheers, John.