Correct, but it doesn't mean that Kotlin concider ...
# announcements
g
Correct, but it doesn't mean that Kotlin concider this type as non nullable, it allows you to decide
s
if I remember right, there are some cases where the compiler will warn you in an un-annotated assignment if things are ambiguous, but I have no idea when specifically that happens
d
What's the distinction between "let me decide" and "assume it's not null"?
is there anything, even a compiler warning, to flag these in my codebase?
g
Difference is that compiler doesn't allow you to use nullable type as non nullable and warn you if you use non nullable as nullable, but platform type is type with unknown nullability that can be used in both ways. Check talk from Andrey Breslav, hi explains this choice. And there is no such flag in compiler. You can find a topic on Kotlin Forum about this with some proposals and comments from Kotlin Team
p
And hence the million dollar mistake remains unsolved. 🙂
Nice slide from the video:
Copy code
Kotlin = null-safe

    Kotlin + Java = as safe as Java
It seems really hypocritical to sell Kotlin as a null-safe language when most of its power comes from reusing Java libraries anyway and if that's the case it is no longer any safer than Java.
d
indeed
it's been a big problem in practice for us
I'm surprised there is no opt-in type safety
g
you cannot solve million dollar mistake for code that already made this mistake. Kotlin used this approach before on some versions before 1.0 (everything is nullable by default), but it’s just not so good solution on practice.
Kotlin + Java = as safe as Java
Yes, but you always free to use Kotlin and have null safety. Also, even in case of using Java API Kotlin do not allow to propagate nulls further But again, maybe make sense to rise this question again and ask for some compiler flag or compiler plugin that force all non-annotated types as nullable. At least it will allow people to test this approach