Equality operator for identityless classes

[Dan Smith]

On Nov 3, 2021, at 9:58 AM, Kevin Bourrillion <kevinb at google.com<mailto:kevinb at google.com>> wrote:

Today, things are pretty okay because developers can learn that `==` is a code smell. A responsible code reviewer has to think through each one like this:

1. Look up the type. Is it a builtin, or Class? Okay, we're fine.
2. Is it an enum? Okay, I resent having to go look it up when they could have just used switch, but fine.
3. Wait, is this weird code that actually cares about objects instead of what they represent? This needs a comment.

The problem is that now we'll be introducing a whole class of ... classes ... for which `==` does something reasonable: only the ones that happen to contain no references, however deeply nested! These cannot at all be easily distinguished. This is giving bugs a really fantastic way to hide.

I'm not sure about this leap: while it's true that `==` is sometimes equivalent to `equals`, in general, you can't be sure without deep knowledge about the class. As a coding convention, seems reasonable to me to continue to expect clients to use `equals` rather than trying to develop a finer-grained distinction between different classes. I think it's perfectly fine advice for most code to continue to treat `==` as a smell, like they always have.