> They could have made that default implementation raise an exception, though. That wouldn't be an improvement, tho. Runtime exceptions mean you have to exerci

> They could have made that default implementation raise an exception, though. That wouldn't be an improvement, tho. Runtime exceptions mean you have to exercise that code-path to find something as trivially detectable as comparing a string to an integer. It has to be a compile-time check (or a validation step for an interpreted language). To specifically address your scenario: > If not for this hack, everything that needs to compare things would have to take an explicit comparator function for every separate comparison context to ensure that caller can request "==" or "is" as appropriate for their use case. This is a solved problem in statically typed languages. All it takes is a protocol/interface called "Equatable" or "Comparable" or something like that. Collection.contains is only available if the collection's contents implement that "Comparable" interface/protocol. For every comparable thing, == is a required fn. A good clear example of this is `equatable` in swift https://developer.apple.com/documentation/swift/equatable https://developer.apple.com/documentation/swift/equatable Swift takes the stance that nothing is Equatable unless it opts into the protocol. It also synthesizes a definition of == if the type is simple enough. Another language might say, ok everything is equatable, the default definition is just comparing memory addresses (a->ptr == b->ptr) - but that would still require a and b being of the same type. If you want to compare an Apple and an Orange `==` is the wrong tool. Something like `apple.sameCaloricContent(orange)` i.e. a function that describes how you're comparing two un-alike things would be the right way to handle it.