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: Frédéric Bron (frederic.bron_at_[hidden])
Date: 2009-12-07 05:23:15

> 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>

It would be:
has_operator_less<T, U, R=bool>
as we said in previous discussion we want to address the case where we
compare T with U!=T.

> 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?).

the "don't care" case was a strong requirement from previous discussion.
I like your proposed solution has_operator_less<T, U, dont_care>

dont_care would have to be an empty class maybe boost::type_traits::dont_care?

>> +           plus                    has_operator_plus
>
> These are more complex because we often have mixed mode arithmetic, what
> about:
> has_operator_plus<T, U> ?

right, that is what I meant

> 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.

I am in favor of dont_care

Frédéric