-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#[derive]'d PartialOrd and Ord use variant declaration order, not explicit discriminant values, for (partially) C-like enums #15523
Comments
nominating (for BC-libs, although |
Assigning 1.0, P-backcompat-libs. (I want to write down what the actual ordering that we want for "partial c-like enums" somewhere, as part of solving this.) |
spawned off of PR #15503 |
Re-nominating. Is this still an issue we want to tackle? If so, it probably belongs on beta. |
leaving on the 1.0 milestone, mostly because if we don't actually get around to doing this, it won't be the end of the world (at least, that's IMO) |
@huonw will mentor |
see also #15620 (which strikes me as a logical subtask of this) |
If we're going to fix this, it needs to be for 1.0. It seems ilke it would be better to just use the discriminant value. |
Use `discriminant_value` intrinsic for `derive(PartialOrd)` [breaking-change] This is a [breaking-change] because it can change the result of comparison operators when enum discriminants have been explicitly assigned. Notably in a case like: ```rust #[derive(PartialOrd)] enum E { A = 2, B = 1} ``` Under the old deriving, `A < B` held, because `A` came before `B` in the order of declaration. But now we use the ordering according to the provided values, and thus `A > B`. (However, this change is very unlikely to break much, if any, code, since the orderings themselves should all remain well-defined, total, etc.) Fix #15523
Use `discriminant_value` intrinsic for `derive(PartialOrd)` [breaking-change] This is a [breaking-change] because it can change the result of comparison operators when enum discriminants have been explicitly assigned. Notably in a case like: ```rust #[derive(PartialOrd)] enum E { A = 2, B = 1} ``` Under the old deriving, `A < B` held, because `A` came before `B` in the order of declaration. But now we use the ordering according to the provided values, and thus `A > B`. (However, this change is very unlikely to break much, if any, code, since the orderings themselves should all remain well-defined, total, etc.) Fix #15523
internal: Fix release workflow
That is,
deriving
considersA
the smallest, but it has the largest discriminant.I would think that
#[deriving]
should be changed to use the explicit discriminants (if they are available), but there is some possibility that declaration order may be the correct thing (you can always reorder the variants to match their discriminants).There's also an edge case due to the (apparent?) untypedness of enum variant discriminants: when ordering
enum Foo { A = 1, B = -1 }
, is the discriminant ofB
considered negative, or is it positive and huge?The text was updated successfully, but these errors were encountered: