On Thu, 08 Oct 2009 20:38:24 -0700 Jeffrey Hellrung <jhellrung@ucla.edu> 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