I still think this could be considered a bug. One of Kotlin stated goals is to reduce NPEs. Yes, with the way that platform types work this behavior is expected, but I think one can argue that there can (and should) be an exception for operators.
- there is only one operator, which can be defined from within java. This alone warrants special treatment of the interop here. (Ok not true,
==
also can be, but equals
handles null
)
- the contract for
Comparable
states:
The natural ordering for a class C is said to be consistent with equals if and only if e1.compareTo(e2) == 0 has the same boolean value as e1.equals(e2) for every e1 and e2 of class C. Note that null is not an instance of any class, and e.compareTo(null) should throw a NullPointerException even though e.equals(null) returns false.
This means that the argument for compareTo
basically has a NotNull
annotation implied (although it is not stated in code.
I think it is fair to say, that calling compareTo
with null is nearly never intended and if the caller wants an NPE there is always !!
.