According to § Cross-crate considerations for PartialEq:

Upholding the requirements stated above can become tricky when one crate implements PartialEq for a type of another crate (i.e., to allow comparing one of its own types with a type from the standard library). The recommendation is to never implement this trait for a foreign type. In other words, such a crate should do impl PartialEq<ForeignType> for LocalType, but it should not do impl PartialEq<LocalType> for ForeignType.

There seems to be two mistakes. The first is the use of "i.e.," which should instead be "e.g.," since std is an example of "another crate". The second, and the one relevant to this post, is that it's very common to implement PartialEq<LocalType> for a type in core/alloc/std, so it seems that those crates should be excluded from the recommendation, right? Also, I rather like the ability to call a == b or b == a without fear of a compilation error; so I feel that the wording might be too strong.

Before I submit a PR, I'd like other opinions. It seems too extreme to recommend against implementing something like PartialEq<MyType> for u32.

I'll add that for many years the documentation was too extreme in the other direction where it used to say that a type A implements PartialEq<B> iff B implements PartialEq<A>. For many that was considered too extreme especially for private types, so I'm glad the documentation was amended to relax that requirement. This change seems to go too far in fixing that though.

1 post - 1 participant

Read full topic