Why is "".equals(1) Valid but "" == 1 Invalid in Kotlin?

Question

I'm currently learning Kotlin and encountered a behavior that I find puzzling. Here are the two lines of code that have me confused:

"".equals(1) // not compile error
"" == 1 // compile error

"".equals(1) - This line compiles and runs without any issues.

"" == 1 - However, this line results in a compile-time error.

From my understanding, in Kotlin, the == operator is translated into a call to the equals method. So I'm curious why the first statement is considered valid while the second one is not, despite both seemingly attempting to do the same comparison between a String and an Int.

Could someone explain the underlying mechanics in Kotlin that make the first statement compile and run, but not the second?

Answer 1

== does usually end up calling equals, but it's not entirely equivalent. One of the inequivalences is a compile-time type check, designed to catch simple bugs. From the docs:

Kotlin checks the applicability of value equality operators at compile-time and may reject certain combinations of types for A and B. Specifically, it uses the following basic principle.

If type of A and type of B are definitely distinct and not related by subtyping, A == B is an invalid expression and should result in a compile-time error.

Informally: this principle means “no two objects unrelated by subtyping can ever be considered equal by ==”.

So because "" and 1 are unrelated by subtyping, Kotlin decides that you probably made a mistake when writing this expression, and it aborts with a compile-time error. This check doesn't apply for equals.

Answer 2

The equals function

equals is a function defined on every Kotlin object and its signature is:

fun equals(other: Any?): Boolean

Therefore by definition the argument to equals can be any other object.

If equals is called with an argument of distinct type to the class defining the function, then the compiler could know that the result to equals was false in advance¹. However it does not flag an error on such a call primarily because any such rule would create a significant anomaly in the language by preventing a function being called with syntactically correct arguments.

The == operator

On the other hand, == is an operator and not a function and thus Kotlin can freely define its behaviour. This behaviour is fully documented in the language specification.

Although == is normally the same as calling equals(), there are a number of differences. Most prominently, the one you observed (since you attempted to use == to compare a String and an Int):

If type of A and type of B are definitely distinct and not related by subtyping, A == B is an invalid expression and should result in a compile-time error.

But also there are other interesting cases, such as:

if the compiler implementation can prove that A === null or B === null or A === B, [the call is] optimized to never call equals function at all

In other words, if == is called on two identical objects and the compiler knows that, equals will not be called and Kotlin can simply return true.

---

¹Although, such a conclusion would be based on the compiler assuming that equals was properly defined to follow its contract (ie rules such as A.equals(A) returns true). While it could do this, this would also be quite surprising and anomalous behaviour when one would expect the function to be called.