Is there ever an instance when you do want to compare object identity instead of “equal”-ness? I find this behaviour just confusing for beginners and not useful for experts.
There are use cases. Like containers where the pointer to the object itself is the key (for example a set). But they are niche and should be implemented by the standard library anyway. One of the things I hate most about Java is .equals() on strings. 99.999% of times you compare strings, you want to compare the contents, yet there is a reserved operator to do the wrong comparison.
Is there ever an instance when you do want to compare object identity instead of “equal”-ness? I find this behaviour just confusing for beginners and not useful for experts.
There are use cases. Like containers where the pointer to the object itself is the key (for example a set). But they are niche and should be implemented by the standard library anyway. One of the things I hate most about Java is .equals() on strings. 99.999% of times you compare strings, you want to compare the contents, yet there is a reserved operator to do the wrong comparison.
Java has the hash interface for using in containers. You don’t need to override equality for it.
99.99% of the time you want to compare by value, which is why languages defaulting to comparing by reference is a stupid default.
Not to take away from your very good point, but I think the word you might be looking for is “eqivalence”.
Maybe if you have to check if the object is one you already hold a lock for or account for some similar consequence of questionable architecture.