-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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_partial_eq_without_eq should acknowledge the constraint it adds #9063
Comments
I do not think that the benefit of having people consider also implementing At the very least, it should not suggest adding |
I came here after hearing criticism over this lint. I have to agree that it feels like a mistake having it as warn by default. It introduces unnecessary noise to packages choosing to be more conservative about what impls to expose. Part of me suspects that the C-COMMON-TRAITS had some influence on how it was raised, considering that it advocates for making types implement as many traits as it can. The real design decision criterion is not that clear-cut, but more of a balance between early interoperability and API stability. |
I was just surprised by this. |
Also enforce mod.rs module style, and allow PartialEq without Eq due to this: rust-lang/rust-clippy#9063
Also enforce mod.rs module style, and allow PartialEq without Eq due to this: rust-lang/rust-clippy#9063
Also enforce mod.rs module style, and allow PartialEq without Eq due to this: rust-lang/rust-clippy#9063
Also enforce mod.rs module style, and allow PartialEq without Eq due to this: rust-lang/rust-clippy#9063
Also enforce mod.rs module style, and allow PartialEq without Eq due to this: rust-lang/rust-clippy#9063
This may pose some problems in the future if we ever extend these structures with fields that support PartialEq, but not Eq, such as floating point types, see: rust-lang/rust-clippy#9063 Signed-off-by: Ariel Miculas <amiculas@cisco.com>
Also enforce mod.rs module style, and allow PartialEq without Eq due to this: rust-lang/rust-clippy#9063
Also enforce mod.rs module style, and allow PartialEq without Eq due to this: rust-lang/rust-clippy#9063
So what's the best proposed solution for derive_partial_eq_without_eq lint would be?
|
@nyurik As I wrote when I filed this issue:
I have no strong opinion on the other elements given that it is now not warn-by-default. |
I opened #12153 which should mitigate this issue a bit by non emitting the lint on non-exhaustive types. |
Don't emit `derive_partial_eq_without_eq` lint if the type has the `non_exhaustive` attribute Part of #9063. If a type has a field/variant with the `#[non_exhaustive]` attribute or the type itself has it, then do no emit the `derive_partial_eq_without_eq` lint. changelog: Don't emit `derive_partial_eq_without_eq` lint if the type has the `non_exhaustive` attribute
Don't emit `derive_partial_eq_without_eq` lint if the type has the `non_exhaustive` attribute Part of #9063. If a type has a field/variant with the `#[non_exhaustive]` attribute or the type itself has it, then do no emit the `derive_partial_eq_without_eq` lint. changelog: Don't emit `derive_partial_eq_without_eq` lint if the type has the `non_exhaustive` attribute
Summary
The
derive_partial_eq_without_eq
lint and its documentation recommends derivingEq
wheneverPartialEq
is implemented on a public type. However, doing so may constrain the evolution of a library: addingderive(Eq)
prevents later adding a private field, or public field or variant in anon_exhaustive
enum or struct, which contains an!Eq
type such asf64
.Notably, Clippy reported this lint on my library's non-exhaustive error enums — types that are more likely than most to gain new variants with new kinds of data.
At a minimum, the lint documentation should acknowledge that adding
Eq
constrains future choices.Lint Name
derive_partial_eq_without_eq
Reproducer
I tried this code:
I saw this happen:
Version
Additional Labels
No response
The text was updated successfully, but these errors were encountered: