Concept requirements on ranges::sort (or ordered_less) may be surprising about range-v3 HOT 2 CLOSED

1. Should ranges::sort default to requiring TotallyOrdered? ranges::less
   may be less (ha ha) surprising to users. (In my case I can and will just
   define operator== etc, but I can imagine there may be cases where that is
   not desirable.)

What cases? Are they imaginary or do you have examples that serve a
practical purpose?

Please do not try to drive algorithm requirements based on imaginary use
cases.

2. Is it necessary for less to require the presence of operators >, <=,
   and >=? I understand that all of these operators should be defined if any
   are, but it still feels surprising that less is not callable on a type
   that defines operator<. (At least when we do get concepts the error
   messages will finally be understandable)

These are both reasonable requirements. Those algorithms are derived from
the concept of a total order (or in some case a weak order) and their
associated operations.

For example, if you can call less(), surely you can call greater() -- after
all, if something is not less, then it may be greater, right? And of course
greater() is defined using >.

Oops, now rule_t works with less() but not greater(). This also means that
you can't sort() in descending order.

I know that greater() is not defined in this library, but it is defined by
the standard, and it's defined to use >.

Andrew

from range-v3.

What cases? Are they imaginary or do you have examples that serve a
practical purpose?

No, I don't have an example; I was simply speculating. Sorry for the noise.

from range-v3.