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: Seth Bunce (seth_at_[hidden])
Date: 2009-10-09 04:28:56

On Thu, 08 Oct 2009 20:38:24 -0700
Jeffrey Hellrung <jhellrung_at_[hidden]> wrote:

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

Thank you for the information regarding possible uses of these type
traits. I had the idea in my head that there was no possible use
other than added convenience for library writers. Your examples clearly
contradict that.

Based on the false idea I held I reasoned that there were only potential
abuses, and no potential benefits.

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

Not at all! As a long time boost user I've always been very impressed
with the quality of the libraries I've used. :-)

        -Seth