update: clarify null-handling behavior of==operator #4808
Conversation
|
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
|
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
|
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
daniCsorbaJB
force-pushed
the
clarify-equal-operator
branch
from
f3e5341 to
8beefa7
Compare
docs/topics/operator-overloading.md
Outdated
| Kotlin calls `.equals()` when neither operand is the `null` literal and the comparison isn’t between two floating-point types. | ||
| Otherwise, `===` is used for `null` literal checks, and non-null floating-point values are compared by numeric value. |
There was a problem hiding this comment.
Instead of "the null literal" can we say "a null value"?
And "=== is used to check for null values" rather than "=== is used for null literal checks"?
And can you make the second sentence active? "Kotlin uses ===" or something like that?
There was a problem hiding this comment.
Instead of "the null literal" can we say "a null value"?
🤔 It's an important difference here. With two expressions A and B, A == B expands to A?.equals(B) ?: (B === null) even with a null value. If either operand is literal null, A == B instead expands to A === B.
And can you make the second sentence active? "Kotlin uses ===" or something like that?
Sure thing 👍
This update is intended to clarify the null-handling behavior of the
==operator for KT-74113Restructured text approved by Nikita Bobko