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.
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”.
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.
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.