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
> < less has_operator_less
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
These are more complex because we often have mixed mode arithmetic, what
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
Just my 2c, John.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk