Explanation that fields are being used when deriving (Partial)Ord on enums#118714
Merged
bors merged 1 commit intorust-lang:masterfrom Jan 22, 2024
Merged
Conversation
Collaborator
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @joshtriplett (or someone else) soon. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
rustbot
added
S-waiting-on-review
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Noratrieb
approved these changes
Jan 21, 2024
Member
Noratrieb
left a comment
Noratrieb
left a comment
There was a problem hiding this comment.
Thanks! Ignore the CI failure here, that was caused by a different thing that's fixed now.
Member
|
@bors r+ rollup |
Collaborator
bors
added
S-waiting-on-bors
TaKO8Ki
added a commit
to TaKO8Ki/rust
that referenced
this pull request
Jan 21, 2024
…_field, r=Nilstrieb
Explanation that fields are being used when deriving `(Partial)Ord` on enums
When deriving `std::cmp::Ord` or `std::cmp::PartialOrd` on enums, their fields are compared if the variants are equal.
This means that the last assertion in the following snipped panics.
```rust
use std::cmp::{PartialEq, Eq, PartialOrd, Ord};
#[derive(PartialEq, Eq, PartialOrd, Ord)]
enum Sizes {
Small(usize),
Big(usize),
}
fn main() {
let a = Sizes::Big(3);
let b = Sizes::Big(5);
let c = Sizes::Small(10);
assert!( c < a);
assert_eq!(a, c);
}
```
This is more often expected behavior than not, and can be easily circumvented, as discussed in [this thread](https://users.rust-lang.org/t/how-to-sort-enum-variants/52291/4).
But it is addressed nowhere in the documentation, yet.
So I stumbled across this, as I personally did not expect fields being used in `PartialOrd`.
I added the explanation to the documentation.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 21, 2024
Rollup of 12 pull requests Successful merges: - rust-lang#118639 (Undeprecate lint `unstable_features` and make use of it in the compiler) - rust-lang#118714 ( Explanation that fields are being used when deriving `(Partial)Ord` on enums) - rust-lang#119801 (Fix deallocation with wrong allocator in (A)Rc::from_box_in) - rust-lang#119948 (Make `unsafe_op_in_unsafe_fn` migrated in edition 2024) - rust-lang#119999 (remote-test: use u64 to represent file size) - rust-lang#120058 (bootstrap: improvements for compiler builds) - rust-lang#120160 (Manually implement derived `NonZero` traits.) - rust-lang#120177 (Remove duplicate dependencies for rustc) - rust-lang#120185 (coverage: Don't instrument `#[automatically_derived]` functions) - rust-lang#120194 (Shorten `#[must_use]` Diagnostic Message for `Option::is_none`) - rust-lang#120200 (Correct the anchor of an URL in an error message) - rust-lang#120203 (Replace `#!/bin/bash` with `#!/usr/bin/env bash` in rust-installer tests) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 22, 2024
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#118714 ( Explanation that fields are being used when deriving `(Partial)Ord` on enums) - rust-lang#119710 (Improve `let_underscore_lock`) - rust-lang#119726 (Tweak Library Integer Division Docs) - rust-lang#119746 (rustdoc: hide modals when resizing the sidebar) - rust-lang#119986 (Fix error counting) - rust-lang#120194 (Shorten `#[must_use]` Diagnostic Message for `Option::is_none`) - rust-lang#120200 (Correct the anchor of an URL in an error message) - rust-lang#120203 (Replace `#!/bin/bash` with `#!/usr/bin/env bash` in rust-installer tests) - rust-lang#120212 (Give nnethercote more reviews) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 22, 2024
Rollup merge of rust-lang#118714 - The-Ludwig:explain_ord_derive_enum_field, r=Nilstrieb Explanation that fields are being used when deriving `(Partial)Ord` on enums When deriving `std::cmp::Ord` or `std::cmp::PartialOrd` on enums, their fields are compared if the variants are equal. This means that the last assertion in the following snipped panics. ```rust use std::cmp::{PartialEq, Eq, PartialOrd, Ord}; #[derive(PartialEq, Eq, PartialOrd, Ord)] enum Sizes { Small(usize), Big(usize), } fn main() { let a = Sizes::Big(3); let b = Sizes::Big(5); let c = Sizes::Small(10); assert!( c < a); assert_eq!(a, c); } ``` This is more often expected behavior than not, and can be easily circumvented, as discussed in [this thread](https://users.rust-lang.org/t/how-to-sort-enum-variants/52291/4). But it is addressed nowhere in the documentation, yet. So I stumbled across this, as I personally did not expect fields being used in `PartialOrd`. I added the explanation to the documentation.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When deriving
std::cmp::Ordorstd::cmp::PartialOrdon enums, their fields are compared if the variants are equal.This means that the last assertion in the following snipped panics.
This is more often expected behavior than not, and can be easily circumvented, as discussed in this thread.
But it is addressed nowhere in the documentation, yet.
So I stumbled across this, as I personally did not expect fields being used in
PartialOrd.I added the explanation to the documentation.