Remove requirement that forces symmetric and transitive PartialEq impls to exist

[dtolnay]

Counterexample of symmetry:

If you have an impl like:

impl<T> PartialEq<T> for Ident
where
    T: ?Sized + AsRef<str>

then Rust will not even allow the symmetric impl to exist.

error[E0210]: type parameter `T` must be covered by another type when it appears before the first local type (`Ident`)
 --> src/main.rs:9:6
  |
9 | impl<T> PartialEq<Ident> for T where T: ?Sized + AsRef<str> {
  |      ^ type parameter `T` must be covered by another type when it appears before the first local type (`Ident`)
  |
  = note: implementing a foreign trait is only possible if at least one of the types for which it is implemented is local, and no uncovered type parameters appear before that first local type
  = note: in this case, 'before' refers to the following order: `impl<..> ForeignTrait<T1, ..., Tn> for T0`, where `T0` is the first and `Tn` is the last

Counterexample of transitivity:

Consider these two existing impls from regex and clap:

// regex

/// An inline representation of `Option<char>`.
pub struct Char(u32);

impl PartialEq<char> for Char {
    fn eq(&self, other: &char) -> bool {
        self.0 == *other as u32
    }
}

// clap

pub(crate) enum KeyType {
    Short(char),
    Long(OsString),
    Position(u64),
}

impl PartialEq<char> for KeyType {
    fn eq(&self, rhs: &char) -> bool {
        match self {
            KeyType::Short(c) => c == rhs,
            _ => false,
        }
    }
}

It's nice to be able to add PartialEq<proc_macro::Punct> for char in libproc_macro (#80595), but it makes no sense to force an impl PartialEq<Punct> for Char and impl PartialEq<Punct> for KeyType in regex and clap in code that otherwise has nothing to do with proc macros.

@rust-lang/libs

[rust-highfive]

r? @sfackler

(rust-highfive has picked a reviewer for you, use r? to override)

[dtolnay]

@rfcbot fcp merge

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @KodrAus
• @dtolnay
• @m-ou-se
• @sfackler
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[pthariensflame]

I think we should at least have something that says symmetry and transitivity are encouraged if they can be done without undue difficulty.

[sfackler]

Agreed that it would be good to recommend the symmetric impl when possible.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[pthariensflame]

@sfackler Can you register a Concern, then? (Can I?)

[KodrAus]

This seems reasonable to me. I could imagine we could find ways to help users around symmetry and transitivity issues through error messages or explicitly codified symmetric or transitive functions that polyfill missing impls.

error[E0369]: binary operation `==` cannot be applied to type `B`
  --> src/main.rs:70:15
   |
70 |     let _ = b == a;
   |             - ^^ - A
   |             |
   |             B
   |
   = note: an implementation of `std::cmp::PartialEq` is available for `A`, try `let _ = a == b;`

and for impl PartialEq bounds in functions:

error[E0277]: can't compare `B` with `A`
  --> src/main.rs:71:33
   |
17 | fn needs_partial_eq(a: A, lhs: impl PartialEq<A>) -> bool {
   |                                     ------------ required by this bound in `needs_partial_eq`
...
71 |     let _ = needs_partial_eq(A, B);
   |                                 ^ no implementation for `B == A`
   |
   = help: the trait `PartialEq<A>` is not implemented for `B`, but `PartialEq<B>` is implemented for `A`
   = help: try `let _ = needs_partial_eq(A, std::cmp::symmetric(B));`

Playground

[dtolnay]

I think we should at least have something that says symmetry and transitivity are encouraged if they can be done without undue difficulty.

I don't necessarily agree with this. Skimming the clap PartialEq code that's mentioned in the transitivity counterexample above (https://github.com/clap-rs/clap/blob/a0269a41d4abaf4b0a9ec4f9a059fe62ea0ba3a7/src/mkeymap.rs#L34-L68), it's hard to say it would be "unduly difficult" to write the full set of reverse impls, but at the same time I really see no benefit of clap doing that. I'd rather they just write whatever impls are needed, and not write whatever impls are not needed.

If your recommendation was intended to apply to public APIs only, that seems more suited to API design guidelines than any official requirement of the trait.

[KodrAus]

On the topic of public APIs specifically I opened up a discussion in the API Guidelines for it: rust-lang/api-guidelines#235

[dylni]

Aside from when it's not possible, is there ever a reason to not make an impl symmetric? If they're not, comparisons need to have a specific order, which should only be a style decision. This can make assert_eq inconsistent for tests.

That's why more PartialEq impls were added later to compare Vec and slice: #71660

[dtolnay]

Aside from when it's not possible, is there ever a reason to not make an impl symmetric?

Yes, there is. If I'm only going to perform the comparisons in one direction in my codebase, I'm not going to write 2 impls, one of which is dead code. I pointed this out in #81198 (comment).

[dylni]

Sorry for not reading the comments well enough. I was looking closer through #80595.

If I'm only going to perform the comparisons in one direction in my codebase, I'm not going to write 2 impls, one of which is dead code.

I can understand this, even though I don't think I would do it myself. Requiring both to exist does seem unnecessary, but shouldn't a recommendation stay on this documentation page? If it's in the API guidelines, it might not be seen by those that want to learn more about the trait.

[varkor]

Perhaps it would be worth being able to derive the symmetry after having implemented one direction. I agree that it's better to have both if possible (and the inconsistency in the past has caused problems with generalising some of the existing library methods).

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[m-ou-se]

@bors r+ rollup

[bors]

📌 Commit 8758083 has been approved by m-ou-se

[pickfire]

If this part is updated for styling then Eq part should also be updated. Let me send a pull request.