It's time to use "==" to check if objects are equal

[yuyang9119]

Now that we have the IEqualityOperators interface, there's no reason to continue using IEqualityComparer & IEquatable, because their semantics overlap with "==". Comparing whether two objects are equal should have been a static method from the start, not a member method. It's time to improve collection types like Dictionary and HashSet.

Object comparison (int Compare) is similar.

[huoyaoyuan]

The new interface still need to be explicitly implemented by types.

The unification would need more language and runtime support, especially adding implemented interfaces via extensions.

[tannergooding]

there's no reason to continue using IEqualityComparer & IEquatable

There are many reasons to continue using IEqualityComparer and IEquatable. The two primary reasons are:

1. They are much more extensively supported throughout the entire .NET ecosystem
2. Equals and == do not strictly do the same thing.

I think the first point doesn't really need much elaboration. object.Equals has been around for the entirety of .NET (20+ years). IEquatable<T> has been around since .NET Framework 2.0 (15+ years). While IEqualityOperators has only been around since .NET 7 (2+ years).

The second point requires a bit of elaboration. Namely, object.Equals and IEquatable<T>.Equals have an overall requirement and expectation of behavior. They are expected to behave a particular way and to work alongside GetHashCode(). Similarly, they are required to be defined in a manner that allows them to successfully work with .NET collections. operator ==, however, has no such requirement and can implement a different type of equality as is necessary for the type.

The most notable case for this is System.Single (float) and System.Double (double) where the underlying specification describing these types (IEEE 754) requires that NaN == NaN always return false. This behavior is strictly correct when dealing with IEEE 754 based floating-point numbers. However, it represents a problem when looking to store such values in a collection or particularly when used in a Dictionary/HashSet (because such a value would be irrecoverable if used as the key). Equals accounts for this by ensuring that Nan.Equals(NaN) returns true so that they work as expected in these scenarios.

Which (of Equals or operator ==) is appropriate is ultimately scenario dependent, and while there are a great number of cases where the behavior is identical, this is not universally the case. They can also see subtle behavioral differences with regards to the handling of null inputs; for example. It would not be appropriate for us to prescribe a particular one as universally better or more correct.

IComparable falls into the same overall consideration and can likewise be produce different results compared to the relational operators in some scenarios.

[yuyang9119]

But we can start now, let these collection types support ==, and recommend users to use this method. If == does not meet the requirements (such as the example of float), we should think in the way of "== is the default behavior, special cases are handled specially", rather than "because it has been used for a long time, plus some special cases, so do nothing", this will only go further and further on the wrong path.

[tannergooding]

It is not the wrong path, it is a clear a distinct difference between two APIs and which is correct depends on your scenario.

For the vast majority of code, Equals and CompareTo remains the correct and better option. You should only use == when you know the concrete type or are in an explicitly constrained generic situation where you know you desire that other behavior.

This is not going to change, it would be far too breaking. Nor can it be reconciled/changed 20 years later.

[yuyang9119]

Allowing Dictionary<> to support == wouldn't be harmful, it would just add new functionality to the Dictionary<>, not change existing ones, existing user code would not be affected.

[yuyang9119]

By the way, I think == should have a default behavior similar to IEqualityComparer<T>.Default, rather than having to be manually implemented. Since the existing code that did not manually define == never use == for non-default behavior, so perhaps this situation can be changed without affecting existing code. This way, there's no need to restrict the use of == to generic types that implement the == interface.

[tannergooding]

It would be actively harmful because == is not required to follow the contract required (and never will be). This can and will lead to bugs when a user uses some T.

That being said, it also can't be done because it would require adding a new constraint, which is a breaking change. There is no current way to access == on an unconstrained generic, because you cannot box and invoke an instance method (there is, however, a proposal to add such support to the language and it would require runtime changes: dotnet/csharplang#6308). It would also never be used over Equals because that would be a breaking change and object.Equals() always exists.

In a hypothetical world where these concerns didn't exist or could be solved with additional checks, it would only be used for types explicitly not following best and recommended practices. This makes it something that we wouldn't add, because it would effectively hurt the mainline/core scenario.

---

operator == and Equals are not the same, this can not and will not change.

Users fundamentally need to override Equals when you implement operator ==. The default analyzers we have will recommend you do that exactly that (CA1066, CA1077, CS0660, CS0661, etc)

So unless you are explicitly violating recommended practices, you will never be in a scenario where you have operator == and do not correspondingly implement the Equals method. If you are violating such recommended practices, you will run into numerous other problems with your types. You will likewise potentially hit issues if you are doing something that requires equality to behave a certain way and the underlying types have differing implementations between operator == and Equals, such as is the case for IEEE 754 floating-point types, but which may also be true for other cases. -- bool for example has 256 possible states, Equals takes this into account while == does not. This isn't normally an issue because most code only has 0 (false) or 1 (true), this is also all that C# considers "valid", and so never has to consider other representations of true (which IL allows, since IL defines it as 0 is false, anything else is true).

There may be cases where Equals and operator == have the same behavior and there may be cases where their behavior differs. Which you use depends on your scenario and context and it is something you have to mindful of.