Excluding the empty range case, handling Ord values is pretty straightforward. However, implementing range comparison with only PartialOrd is non-trivial.

As a simple non-total partial order, we can use the relation “divides”. For instance, 2 divides 6 and 3 divides 6, but 4 does not divide 6. This is a partial order because:

• reflexivity: for any natural integer (including 0) x, x divides x
• antisymmetry: for any natural integers x and y, if x divides y and y divides x, then x = y (it follows naturally from the fact that, if x divides y, then x ≤ y)
• transitivity: for any natural integers x, y and z, if x divides y and y divides z, then x divides z

However, this is not a total order, because 4 does not divide 6 and 6 does not divide 4.

Now, given x, y and z that implement the PartialOrd describe above, what should the relation between x and y..z be?
Note that, by definition, y..z contains all a such that verify: x divides a and a divides z. Let us consider a few cases:

1. with 4 and 2..8 : since 2 divides 4 and 4 divides 8, the result is clearly Inside
2. with 2 and 4..8 : since 2 divides 4, the result is clearly Below
3. with 8 and 2..4 : since 4 divides 8, the result is clear Above
4. with 3 and 2..8 : since 3 is not in the interval 2..8, it should not be considered Inside for this order
5. with 3 and 4..8 : since 3 does not divide any element of 4..8, we cannot say that it is Below for this order
6. with 9 and 2..4 : since no element of 2..4 divide 9, we cannot say that it is Above for this order

Now, the mathematical definition is valid when y divides z. But Rust's range types do not enforce this, so we have an additional case to handle:

7. with 4 and 2..7 : 2 does not divide 7, so it is not covered by the definition

And finally, #6 applies as well:

8. with 4 and 8..2 : the interval is empty, so comparison is meaningless

Cases 1, 2, 3 are open-and-shut. I think 4 through 8 should return None as per PartialOrd semantics. 8 is more debatable.

Currently, comparing a value to the empty set yields different results, depending on how it is represented:

        assert_eq!(30.range_cmp(45..35), RangeOrdering::Below);
        assert_eq!(30.range_cmp(25..15), RangeOrdering::Above);

If we want to follow the semantics of the set of values represented by the range, none of these is actually correct, and we should add a new variant for RangeOrdering for this case.

We could also decide that we want to keep this behavior, since the representations 45..35 and 25..15 actually represent different objects.