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: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-12-07 06:36:39

On Mon, Dec 7, 2009 at 9:12 PM, John Maddock <john_at_[hidden]> wrote:

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

Perhaps

boost::has_operator_less<T,R=bool>

Is "less ugly" than

boost::operators::less::exists<T, R=bool>

But is it 'better'?

Using boost::operators::[name] has enough potential benefits that I don't
see why it should be rejected so casually:

* boost::operators::[tab]::[tab] works better with Intellisense
* it is factored over the operators, which provides a common structure for
all operators in a tree
* it provides a single type that designates each operation uniquely. that
is, operators can become first-class objects.

Christian