hyperium
Custom total `Ord` for `Uri` and its parts
The user requesting Ord for Uri in #407 suggests that some or even any impl of PartialOrd and Ord for Uri is helpful for composition. Its also necessary for inserting into BTreeMap and BTreeSet. The Authority and Scheme parts already have case-insensitive custom Eq impls (or in the case of Authority, PartialOrd). To have implemented Eq and PartialOrd without Ord could be viewed as a unintended omission.
Since the crate can offer but one total ordering for Uri, I argue here that the most natural ordering is by delegation to the parts in the order shown below, e.g. by (primary, secondary, tertiary) keys (Authority, Scheme, PathAndQuery). To use Scheme as the secondary key (after Authority) is somewhat arbitrary, but subjectively, this better relates the relationships of DNS lookup, TLS, ports and paths. The next most obvious ordering would be (Scheme, Authority, PathAndQuery). Its breaking to change it later, so best to consider this fully, before merging.
| Type | Ordering | PR Commits |
|---|---|---|
Authority |
(existing PartialOrd + Eq) case-insensitive |
b2d1ea6 |
Scheme |
(existing Eq) case-insensitive |
12eeefd |
PathAndQuery |
(existing PartialOrd + Eq) byte-wise |
09bcf39 |
Uri |
(existing Eq) compatible new: (Authority, Scheme, PathAndQuery) |
6d73729 |
Regarding when to merge this, I'd wait for 1.0.0, treating it as the new feature it is.
(Implements) closes #407
I love the proposed ordering, I think it is the most useful one and don't see any downsides to the other one. (the other one is of course closer to the ordering of the same URI's string representations, but since they'd only be closer, not identical, that wouldn't be helpful IMHO)
