Does anyone know the reason why `==` is less permi...
# announcements
j
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()`:
Copy code
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?
c
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.
j
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?
c
it is not safe (in terms of avoiding hard to catch bugs) to compare a char and a string with
==
.
j
Yes, but it is just as unsafe to use
equals()
, and this one compiles fine.
c
yes, but that is part of Java Object interface, so
equals
has to remain.
πŸ‘ 1
j
Ok that's what I thought, thanks for clarifying
@Jonathan Mew Good point, although it doesn't seem related to boxing, because using this custom class yields the same behaviour:
Copy code
class X {
    override operator fun equals(other: Any?): Boolean {
        return true;
    }
}
j
Sorry, I'm not quite following. Would you mind showing the code which shows the similar behaviour using X?
Oh, are you doing
Copy code
x = X()
x == "something"
x.equals("something")
And it complains about x == "something"
πŸ‘ 1
j
@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.
j
cool, had not noticed this πŸ™‚
j
@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.
j
yeah, just tried it, interested in gaining some insight now!
😊 1
j
@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
?
c
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.
j
@Czar I see, I think things are clearer now. Thanks a lot for explaining.
c
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 ^_^
j
We're in the same boat, don't worry πŸ™‚
πŸ™‚ 1
j
I have no good excuse for my poor communication .. 😢
thanks @Czar!
πŸ‘ 1
p
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
πŸ‘ 3
j
@Pavlo Liapota good to know, thanks!