Concept requirements on ranges::sort (or ordered_less) may be surprising

[cordarei]

I found an instance where ranges::sort(vec) fails to compile but std::sort(vec.begin(), vec.end()) compiles. The type of vec is std::vector<rule_t>, and the definition of rule_t is:

struct rule_t {
  rule_t(std::string lhs, std::vector<std::string> rhs, double prob)
    : lhs_{std::move(lhs)}, rhs_{std::move(rhs)}, prob_{prob}
  {}

  std::string const & lhs() const { return lhs_; }
  std::vector<std::string> const & rhs() const { return rhs_; }
  double const & prob() const { return prob_; }

private:
  std::string lhs_;
  std::vector<std::string> rhs_;
  double prob_;
};
bool operator<(rule_t const &left, rule_t const &right) {
  return std::tie(left.lhs(), left.rhs()) < std::tie(right.lhs(), right.rhs());
}

This is because the concept requirements on ordered_less (and ranges::less as well) are stricter than the (non-existent) ones in the standard library.

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.)

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).

[asutton]

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

[cordarei]

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.