Fix handling of empty range

[qsantos]

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.

[qsantos]

Note that ..0u32 is empty. Have fun implementing is_empty over arbitrary RangeBounds.

[adriendellagaspera]

Resolved by the semantics rework in #13 (commit 4d4946b).

The crate now handles empty ranges explicitly rather than returning an arbitrary, representation-dependent verdict:

• A new RangeOrdering::Empty variant is returned for empty/inverted ranges, so 30.rcmp(45..35), 30.rcmp(25..15) and 0.rcmp(0..0) all yield RangeOrdering::Empty.
• This follows the "keep representation semantics but add a dedicated variant" option from the discussion: emptiness is judged from the bounds, not from the population of the type. As noted here, ..0u32 is therefore treated as a regular (non-empty) range, sidestepping the "implement is_empty over arbitrary RangeBounds" problem.
• For partial orders, the new PartialRangeOrd::partial_rcmp returns a RangePosition (the pair of BoundOrdering relationships to each bound), and RangePosition::ordering() collapses the (Outside, Outside) case — only reachable for an inverted range — to RangeOrdering::Empty.

Closing as completed.

---

Generated by Claude Code