Re: [boost] review request: addition to type_traits library of is_less_comparable<T, U> and others

Subject: Re: [boost] review request: addition to type_traits library of is_less_comparable<T, U> and others
From: Jeffrey Hellrung (jhellrung_at_[hidden])
Date: 2009-10-08 23:38:24

Seth Bunce wrote:
> Is there some practical advantage to having type traits for all of these operators?
> 
> "<=, >, >=, ==, and !=" can all be expressed in terms of "<".

IIRC, there was already a short discussion on this recently (also in the 
context of this library), with the conclusion being that this is not 
always the case.  You might want to search the archives...?

What immediately comes to my mind are expression templates (e.g., 
Boost.Proto).  This is also a case where the return type is not 
necessarily convertible to bool.  I don't think this library should 
decide whether it's appropriate for a client of this library to test 
operator< for such types; leave that decision for the client.

Also, it makes sense for some types to return, e.g., a boost::tribool; 
Boost.Interval is such an example.  Though convertible to bool, a user 
may be interested that the result of operator< is, specfically, a 
boost::tribool, and, e.g., throw if the result is indeterminate.

> It seems like if all of the operators are supported it will encourage boost developers to move complexity from the back end (what boost developers see) to the front end (what users see).
> 
> If a boost developer requires a user defined type to specify more than "<" for the purpose of doing any of "<, <=, >, >=, ==, and !=", it effectively moves complexity to the front end.
> 
> 	-Seth

Are you saying that boost's current quality controls are insufficient to 
catch unnecessary developer-imposed requirements on the client? ;)

To reiterate, I didn't get the sense that the scope of this library was 
to dictate semantics.  It seems more like a syntactic querying tool.  I 
may have misinterpreted Frederic's and the library's intents, though ;)

- Jeff