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