document PartialEq, PartialOrd, Ord requirements more explicitly #85637
Conversation
|
(rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
| /// - transitivity: `a < b` and `b < c` implies `a < c`. The same must hold for both `==` and `>`. | ||
| /// - duality: `a < b` if and only if `b > a`. |
There was a problem hiding this comment.
This is probably the most questionable part of this PR -- it could be considered a new requirement. On the other hand, given that we demand symmetry for ==, it would seem really strange to not also demand duality here.
| /// - transitivity: `a < b` and `b < c` implies `a < c`. The same must hold for both `==` and `>`. | ||
| /// - duality: `a < b` if and only if `b > a`. |
There was a problem hiding this comment.
This is probably the most questionable part of this PR -- it could be considered a new requirement. On the other hand, given that we demand symmetry for ==, it would seem really strange to not also demand duality here.
| /// The comparison must satisfy, for all `a`, `b` and `c`: | ||
| /// | ||
| /// - asymmetry: if `a < b` then `!(a > b)`, as well as `a > b` implying `!(a < b)`; and |
There was a problem hiding this comment.
I removed this line because:
- It is redundant: it already follows from
a < bbeing defined aspartial_cmp(a, b) == Some(Less), which implies!(a > b)(defined aspartial_cmp(a, b) != Some(Greater)). - "asymmetry" is the wrong term, an "asymmetric" relation is a relation that satisfies "if
a < bthen!(b < a)".
asymmtery (in the correct sense of the word) is a consequence of duality, so we could state it in the corollary section if you wish. antisymmetry is more closely related to what the docs are currently stating, but it is defined for <=-style relations: R is antisymmetric if R(a, b) && R(b, a) implies a == b.
| /// - transitivity: `a < b` and `b < c` implies `a < c`. The same must hold for both `==` and `>`. | ||
| /// - duality: `a < b` if and only if `b > a`. |
There was a problem hiding this comment.
There is another property here that we might want to add: compatibility of partial_cmp with ==:
when a1 == a2 and b1 == b2, then partial_cmp(a1, b1) == partial_cmp(a2, b2).
|
cc @rust-lang/libs |
| /// If [`PartialOrd`] or [`Ord`] are also implemented for `Self` and `Rhs`, their methods must also | ||
| /// be consistent with `PartialEq` (see the documentation of those traits for the exact | ||
| /// requirememts). It's easy to accidentally make them disagree by deriving some of the traits and | ||
| /// manually implementing others. |
There was a problem hiding this comment.
I think this sentence is begging for a code example. I was saying to myself, "Oh wow, I should watch out for that, I'm hoping an example comes next" while reading it.
There was a problem hiding this comment.
Note that I did not write this sentence, I just moved it around. I don't know what the original author had in their mind when writing this.
There was a problem hiding this comment.
So what I am saying is, this issue is pre-existing, and I hope my PR doesn't have to fix it. :) It seems largely orthogonal to what this PR is about.
| /// If [`Ord`] is also implemented for `Self` and `Rhs`, it must also be consistent with | ||
| /// `partial_cmp` (see the documentation of that trait for the exact requirements). It's | ||
| /// easy to accidentally make them disagree by deriving some of the traits and manually | ||
| /// implementing others. |
There was a problem hiding this comment.
Same thought as above on an example.
…rties are ensured by default impls
JohnCSimon
added
S-waiting-on-review
|
@rust-lang/libs this has been sitting without a review for quite some time now |
m-ou-se
added
the
T-libs-api
|
Since unsafe code can't count on these requirements anyway, we don't have to be too careful with adding clarifications like this about what these traits mean. None of your changes are surprising new requirements. Just clarifications of what was already implied/known. Thanks! @bors r+ We might want to clarify that 'must' in this documentation doesn't mean you get UB otherwise, and that you may not rely on these guarantees in unsafe code. The HashSet documentation contains:
We could add something like that here too. |
|
📌 Commit 45675f3 has been approved by |
bors
added
S-waiting-on-bors
That would be #73682. Could you post your suggestion there? |
document PartialEq, PartialOrd, Ord requirements more explicitly This is the result of discussion in rust-lang#50230, in particular [this summary comment](rust-lang#50230 (comment)). Fixes rust-lang#50230.
Rollup of 8 pull requests Successful merges: - rust-lang#83739 (Account for bad placeholder errors on consts/statics with trait objects) - rust-lang#85637 (document PartialEq, PartialOrd, Ord requirements more explicitly) - rust-lang#86152 (Lazify is_really_default condition in the RustdocGUI bootstrap step) - rust-lang#86156 (Fix a bug in the linkchecker) - rust-lang#86427 (Updated release note) - rust-lang#86452 (fix panic-safety in specialized Zip::next_back) - rust-lang#86484 (Do not set depth to 0 in fully_expand_fragment) - rust-lang#86491 (expand: Move some more derive logic to rustc_builtin_macros) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This is the result of discussion in #50230, in particular this summary comment.
Fixes #50230.