remove_cv.html is not in the archive (the link from index.html was broken).
It is already part of boost but as I use it I should include it in the tarball. Sorry.
The links for the additions are not in alphabetical order on index.html.
Yes, I thought it was better here to have is_less close to is_less_equal but I have no strong opinion on that and can come back to alphabetical order.
Even if you didn't invent the code, you assembled and documented it, so your name should be in the copyright notice (in the documentation), right? Add others to the list as you think appropriate.
OK, I added Roman Perepelitsa and my-self. Roman, if you are still reading this mailing list, do you agree to have your name in the copyright?
Your HTML formatting differs from the original, though that could be the means by which it was generated rather than a difference in the formatting of your files.
I think so because I applied the method recommended by Beman.
Your content will appear in a single page, reference.html, if added to Boost.TypeTraits, so why create separate pages now?
I do not understand your point here. Do you mean I could have all traits on the same page and only one line in reference.html?
The description of is_greater_comparable should be more specific:
If a value of type T can be compared with another using operator > to determine whether the first is greater than the other, then inherits from true_type, otherwise inherits from false_type.
OK for that.
I think is_greater_than can be less restrictive than it is. std::greater() provides an operator that permits comparing unrelated types as T's. Therefore, I wonder if this would work:
template <class T, class U = T> struct is_greater_comparable;
Then, is_greater_comparable<int, float> would inherit from true_type.
Thank you for suggestion (applied) and help finding my error (shame on me).
I can add that one important question of the review is: should we report that T is less comparable if T<T returns void?
I think that is not appropriate as the whole point of less-than-comparable is to be able to determine whether one instance is less than another, not that "operator <" is supported.
Here, I cannot find a way to get the return type of operator<(T, U). The only thing I can do is: 1. do not treat "void operator<(T, U)" => thus using is_less_comparable<T, U> if operator<(T, U) returns void will be a compilation error => no compiler warning for the ternary operator, trick 2. treat "void operator<(T, U)" => must use the ternary operator, trick => compiler warning => is_less_comparable<T, U> is true_type if operator<(T, U) exists and returns void (no compiler error) I am in favour of solution 1 because when we need is_less_comparable<T, U> it is obviously to later do something like "bool result=t<u". Then with solution 1 the compilation error would come when is_less_comparable<T, U> is invoked and with solution 2 it would come when t<u is invoked. So in either case, there will be a compilation error somewhere. Other issue: I do not see how I can test the return type of operator< to check if it is convertible to bool. Frédéric