http
http copied to clipboard
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)