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 05:12:08

> operator    name in <functional>    proposed name (existence)
> proposed name (existence and non void return type convertible to
> something)
> <           less                    has_operator_less
> operator_less_has_standard_behaviour

I don't like operator_less_has_standard_behaviour at all.  In fact is there 
really any point to it?

Why not simply:

has_operator_less<T, R = bool>

Where R is the expected return type.  In all but a vanishingly small number 
of cases R will be bool.  If you really want to support the "don't care" 
case for a return type, use has_operator_less<T, dont_care> where 
"dont_care" is a special placeholder type that you define (could use a 
better name though?).

> +           plus                    has_operator_plus
> operator_plus_has_standard_behaviour

These are more complex because we often have mixed mode arithmetic, what 
about:

has_operator_plus<T, U> ?

In fact an important use case might be to work out if I can add a T to a U 
:-)

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.

Just my 2c, John.