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.