Boost logo

Boost :

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

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, gregod at, cpdaniel at, john at