Is it reasonable to additionally verify the returned type? IMO, such kind of traits should not make assumptions about the operators meaning, they should merely show whether the comparison expression is valid. Thus there also should not be a fails-to-compile case.
OK, what do you know if you know that you can write t<u but do not know if it is convertible to bool? You know that "t<u ;" is OK but maybe "if (t<u) ..." will not work -> compile time error. I think that in most cases you want to know that it behaves like operator< used with built-in types. Maybe it could be interesting for some people to have an additionnal version just checking for existence but I am not convinced. I agree that it is not "nice" to have a compile time error when used with operator< returning void but I prefer that than returning true because this behaviour is not the one expected by operator<. If anybody has a solution on how to return false in such case... Frédéric