Frédéric Bron 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.
I did not think about expression templates but do you see any reason for asking if the expression template is comparable? Normally the user do not bother about expression templates (which is an implementation detail) but only about the result type which is a "normal" type? I may be wrong as I only know expression templates in the frame of uBlas.
Frédéric
First, I'd like to say I think this would be a useful addition to Boost.TypeTraits, and I appreciate your work Frederic ;) There were 2 points that I raised in response to a previous message that I'd like to clearly distinguish: 1) You cannot generally express all comparison operators in terms of operator<, or even in terms of a combination of operator< and operator==. Expression templates were one example I thought of (e.g., Boost.Proto), but it just seems wrong to me for a library to dictate the semantic relationship among the comparison operators. operator< and operator== are enough *most* of the time to get the other comparison operators, but I don't think *all* of the time (though a good example escapes me at the moment). I gather you don't take issue with this, as you provide metafunctions corresponding to all the comparison operators. 2) At the very least, boost::tribool is a legitimate return value (in addition to bool) for any of the comparison operators, which indicates to me that the interface should allow specification of the result type of a comparison operator. - Jeff