Trait for comparisons using the equality operator.

Implementing this trait for types provides the == and != operators for those types.

x.eq(y) can also be written x == y, and x.ne(y) can be written x != y. We use the easier-to-read infix notation in the remainder of this documentation.

This trait allows for comparisons using the equality operator, for types that do not have a full equivalence relation. For example, in floating point numbers NaN != NaN, so floating point types implement PartialEq but not [trait@Eq]. Formally speaking, when Rhs == Self, this trait corresponds to a partial equivalence relation.

Implementations must ensure that eq and ne are consistent with each other:

• a != b if and only if !(a == b).

The default implementation of ne provides this consistency and is almost always sufficient. It should not be overridden without very good reason.

If [PartialOrd] or [Ord] are also implemented for Self and Rhs, their methods must also be consistent with PartialEq (see the documentation of those traits for the exact requirements). It's easy to accidentally make them disagree by deriving some of the traits and manually implementing others.

The equality relation == must satisfy the following conditions (for all a, b, c of type A, B, C):

• Symmetry: if A: PartialEq<B> and B: PartialEq<A>, then a == b implies b == a; and

• Transitivity: if A: PartialEq<B> and B: PartialEq<C> and A: PartialEq<C>, then a == b and b == c implies a == c. This must also work for longer chains, such as when A: PartialEq<B>, B: PartialEq<C>, C: PartialEq<D>, and A: PartialEq<D> all exist.

Note that the B: PartialEq<A> (symmetric) and A: PartialEq<C> (transitive) impls are not forced to exist, but these requirements apply whenever they do exist.

Violating these requirements is a logic error. The behavior resulting from a logic error is not specified, but users of the trait must ensure that such logic errors do not result in undefined behavior. This means that unsafe code must not rely on the correctness of these methods.

Cross-crate considerations

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.

This avoids the problem of transitive chains that criss-cross crate boundaries: for all local types T, you may assume that no other crate will add impls that allow comparing T == U. In other words, if other crates add impls that allow building longer transitive chains U1 == ... == T == V1 == ..., then all the types that appear to the right of T must be types that the crate defining T already knows about. This rules out transitive chains where downstream crates can add new impls that "stitch together" comparisons of foreign types in ways that violate transitivity.

Not having such foreign impls also avoids forward compatibility issues where one crate adding more PartialEq implementations can cause build failures in downstream crates.

Examples

let x = 0;
let y = 1;

assert_eq!(x == y, false);
assert_eq!(x.eq(y), false);

assert!((1.0).eq(1.0));
assert!(!(1.0).eq(2.0));

assert!(1.0 == 1.0);
assert!(1.0 != 2.0);