The documentation is currently clear that null-safety guarantees begin to deteriorate when interacting with non-Kotlin code. I’m not looking to propose a change to default compiler behavior, as I imagine this topic was thoroughly explored and discussed long before my (admittedly recent) adoption of the Kotlin language.
That said, I was hoping to discuss a potential opt-in compiler feature that could enforce more guarded interactions with non-annotated Java code. Consider the following minimal example:
fun uuidFromString(val uuid: String?) = UUID.fromString(uuid)
UUID.fromString() implementation from
java.util is currently non-annotated, and will throw at runtime if it receives a null value. And as we’re bridging Kotlin and Java domains, the Kotlin compiler will not warn or fail when I attempt to invoke this method with a value of the nullable type
I’ve searched around for some rationale on why this was the preferred default compiler behavior, but haven’t seen much beyond a comment suggesting that the alternative was too cumbersome. At any rate, I accept that this is unlikely to change as a default behavior. BUT, is there room to explore compiler options that would enforce more guarded code when bridging the language barrier?
Specifically, as pertains to the code example above, I would love to see a compiler option that rejects any attempt to pass a nullable value to a Java parameter that hasn’t been explicitly annotated as nullable as well. This would also rely on corresponding annotations (on the Kotlin side) that explicitly permit an unguarded invocation in situations where this was deemed safe.
Thanks in advance for any consideration!