On Mon, Dec 7, 2009 at 9:12 PM, John Maddock <john@johnmaddock.co.uk> 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