Does anyone know the reason why `==` is less permissive than its method counterpart `equals()`? The ...

# announcements

[Joffrey]

Does anyone know the reason why == is less permissive than its method counterpart equals()?
The compiler doesn't seem to accept 'c' == "string", but it does accept 'c'.equals("string").

Isn't it supposed to be the same code? In IntelliJ IDEA, when Ctrl+clicking ==, it brings me to the same definition as `equals()`:

public open operator fun equals(other: Any?): Boolean

This is supposed to accept Any?. Did the Kotlin team keep this equals() signature for easier Java interop? In this case, is the inconsistency with == intended in order to provide more type safety?

[Czar]

Yes, this is for safety. Strictly speaking == is not the same as equals, like for instance in your example. == is an operator whose implementation usually follows `equals`' semantics, but when safety is concerned it may be missing altogether.

[Jonathan Mew]

My guess is that it's down to boxing. 'c' == is trying to do a primitive comparison with an object, but 'c'.equals() gets boxed into a Character instance at which point the .equals method is available.
Just a guess though.
@Czar could you expand on the safety thing?

[Czar]

it is not safe (in terms of avoiding hard to catch bugs) to compare a char and a string with ==.

[Joffrey]

Yes, but it is just as unsafe to use equals(), and this one compiles fine.

[Czar]

yes, but that is part of Java Object interface, so equals has to remain.

[Joffrey]

Ok that's what I thought, thanks for clarifying

[Joffrey]

@Jonathan Mew Good point, although it doesn't seem related to boxing, because using this custom class yields the same behaviour:

class X {
    override operator fun equals(other: Any?): Boolean {
        return true;
    }
}

[Jonathan Mew]

Sorry, I'm not quite following. Would you mind showing the code which shows the similar behaviour using X?

[Jonathan Mew]

Oh, are you doing

x = X()
x == "something"
x.equals("something")

And it complains about x == "something"

[Joffrey]

@Czar "Strictly speaking == is not the same as `equals`". Then I may have misunderstood operator overloading in Kotlin. Could you please expand on this? I though declaring plus, equals, compareTo etc in a class was the way to define how operators +, == and > and the likes worked for that class.

[Jonathan Mew]

cool, had not noticed this 🙂

[Joffrey]

@Jonathan Mew Yes, sorry for not showing the code in the first place. This is exactly what exhibits the same behaviour: == does not compile, while equals() does.

[Jonathan Mew]

yeah, just tried it, interested in gaining some insight now!

[Joffrey]

@Czar what do you mean by "is an operator whose implementation usually follows equals semantics"? In the documentation, it says that the usage of operators is "translated to" the methods. Isn't it the case? Or are some shortcuts made for well-known types like Char?

[Czar]

Yes, it is, but treatment of the operator by the compiler is different to the method it points to. That is why '' == "" does not compile.

[Joffrey]

@Czar I see, I think things are clearer now. Thanks a lot for explaining.

[Czar]

Yeah, I should have written my comment thus in the first place.
I see how my previous comment is confusing. English is not my native language ^_^

[Joffrey]

We're in the same boat, don't worry 🙂

[Jonathan Mew]

I have no good excuse for my poor communication .. 😶

[Jonathan Mew]

thanks @Czar!

[Pavlo Liapota]

My two cents about difference between .equals() and == 🙂
- it is safe to compare nullable variables with ==, for ex. nullable1 == nullable2, it will not be transformed directly to nullable1.equals(nullable2)
- if you compare primitives with ==, then .equal() is not called at all

[Joffrey]

@Pavlo Liapota good to know, thanks!