7

This question is not about the differences between == and Equals. It's about why they were designed different.

We know the differences causes many problems, which must have been pretty easy to spot up front:

  • Equals and == yield different results for two instances of the same entity.
  • == yield different results when comparing subclasses, because == is not polymorphic
Soner Gönül
  • 97,193
  • 102
  • 206
  • 364
Thomas Eyde
  • 3,820
  • 2
  • 25
  • 32
  • Steve, how about reading the first line of my question before you jump to conclusions? It's NOT about the difference, but WHY it was designed different. A totally different question. – Thomas Eyde May 23 '15 at 12:32
  • 4
    @Claies I think it’s sufficiently non-obvious. – Konrad Rudolph May 23 '15 at 12:35
  • 1
    Claies, certainly I don't know, because all my searches points to different explanations of the differences. None of them about the different purposes. Why don't you explain the different purposes or post a link? – Thomas Eyde May 23 '15 at 12:35
  • http://blogs.msdn.com/b/ericlippert/archive/2009/04/09/double-your-dispatch-double-your-fun.aspx – Claies May 23 '15 at 12:36
  • Henk, are you referring to my question? If I override Equals, but not ==, then they will already yield different results. One is comparing on an internal value, the other on references. If I implement both, the subclass will not inherit the ==, so using == on subclasses yields different results. – Thomas Eyde May 23 '15 at 12:37
  • 2
    @ThomasEyde *== yield different results when comparing subclasses, because == is not polymorphic* I normally define `==` in the "base" class to call `Equals`, so I solve this problem... – xanatos May 23 '15 at 12:42
  • xanatos, I had to read your comment twice. It doesn't answer my question, but it's a nice trick :-) – Thomas Eyde May 23 '15 at 12:47
  • 1
    @ThomasEyde It shows that the point 2 of your question is 90% moot (it is moot if you "control" the base class). – xanatos May 23 '15 at 12:56
  • @Claies, I followed your link. The closest thing I get from it is that language designers and framework designers think differently. There is something there about users expecting == to be symmetric, a claim which does not apply to me. I want comparing to be consistent. – Thomas Eyde May 23 '15 at 13:05
  • @xanatos, moot to you maybe. Knowing this trick does not answer my question, *why* they were designed differently. Their differences causes all kinds of trouble if we are not careful. And having to be careful is not in the spirit of the language, which wishes to make the proper thing easy for us. – Thomas Eyde May 23 '15 at 13:08
  • what that symmetric comment means is that the compiler knows that both sides of the operator are the same with `==` but it can't know (without reflection) if both sides of `Equals` are. – Claies May 23 '15 at 13:14
  • @Claies, that means only that if I compare a vaiable of `Foo` with a variable of `int`, like `if (foo == n)`, then the compiler would know where to look for equality. I don't see why this alone explains why `.Equals()` and `==` are considered two different things. – Thomas Eyde May 23 '15 at 13:29

1 Answers1

3

The short answer is that the C# language design team and the .NET framework design team couldn't agree on how best to compare values/objects for equality, so each implemented their own system.

For a more technical, detailed answer, please refer to a blog post on the subject by Eric Lippert.

David Arno
  • 42,717
  • 16
  • 86
  • 131
  • 2
    This could be shown by the fact that there is no support in the IL language for operators. They are "built" by the C# compiler (and by other "compatible" languages) using methods (with certain names and with the specialname) flag... https://msdn.microsoft.com/en-us/library/aa735713(v=vs.71).aspx ***Operator overloading is not in the CLS**. However, the CLS provides guidelines about providing useful names (such as Add()) and setting a bit in metadata. Compilers that choose to support operator overloading should follow these guidelines but are not required to do so.* – xanatos May 23 '15 at 13:21
  • As Eric Lippert, a former Language Designer for C#, agrees that the Framework Designers probably made the correct framework decision, your over simplifying paraphrase becomes *grossly inaccurate*. Your answer then becomes worse than a link-only answer, as it misrepresents the lik it points to. – Pieter Geerkens May 23 '15 at 13:22
  • 1
    @PieterGeerkens, there are two (actually three, but let's stick to two) ways of doing equality in C#/.NET. So if you rule out that two groups couldn't agree and so implemented two different systems, we are left with the idea that a single consensus group thought it would be a good idea to create two incompatible equality systems. Somehow, I think my summary, far from being "grossly inaccurate" is a highly accurate statement of fact, for the alternative is very worrying. – David Arno May 23 '15 at 13:36
  • @xanatos, doesn't this contradict what HansPassant answered? – Thomas Eyde May 23 '15 at 13:46
  • @ThomasEyde If you open the PDF he pointed at (he removed the answer, but the link is to http://www.ecma-international.org/publications/standards/Ecma-335.htm), you'll see that the only place where `op_Equality` is named (other than the index) is in the `I.10 Name and type rules for the Common Language Specification` – xanatos May 23 '15 at 14:29
  • Thank you all for the interesting comments. – Thomas Eyde May 24 '15 at 19:53