I read the blog post about "how I can contribute t...

# language-proposals

[Cies]

I read the blog post about "how I can contribute to Kotlin's future". There's one thing that I'd really like to see changed in Kotlin: it's handling of platform types. My team has been bitten too many times by platform types. Probably everyone who needs interop with Java code/libraries has had this problem. Now I dont mind that platform types exist, but I do mind that they are "treated as nonnull while they are certainly nullable". This is the biggest cause for NPEs that we find.

IMHO a copmiler flag (like "warningsAsErrors") would be a good solutions, e.g. "treatPlatformTypesAsNullable". But maybe a compiler plugin could also be useful. On top of that we obviously also want the IDEA to follow along and give the right type hints. I'm not sure where to put this idea, should i create a KEEP for it? Or does anyone know if a similar proposal exists?

[Ben Woodworth]

Not a proposal, but some insight/history:

https://youtu.be/Uizh2WlJtnk?t=1518▾

Basically treating everything from java as nullable is how Kotlin worked at one point before 1.0, but community feedback showed that it wasn't pragmatic because of all of the null checks and non-null assertions that needed to be added everywhere

[Cies]

@Ben Woodworth "community feedback showed that it wasn't pragmatic because of all of the null checks and non-null assertions" we might as well use JRuby then! (joking) ... thanks for your insight! I do believe that the current solution is intellectually dishonest: it at least should be a switch (that's set on "dangerous" by default) i think.

[Cies]

@Ruckus But why not have a switch for this? So that platform can be treated as nullable, or as platform currently is, or maybe a third option that merely gives warnings...

[Cies]

@Ruckus When it isn't certain that it nonnull, it should be treated as nullable. this is called erring on the side of safety. I understand this is not done for "an easy onramp" or for "marketing purposes", but it is not honest, and worse: i bit me several times.

[Ben Woodworth]

An aside, but are jetbrains annotations an option? Kotlin picks up on @Nullable and @NonNull annotations

[Cies]

@Ben Woodworth they'd require quite large commits to libraries that we depend on. and we depend on quite a few libraries. in cases where we've been bitten, and it was possible to make such a contribution, i did.

[Cies]

@Ruckus "Due to community feedback" the null safety of Kotlin was forever compromised when it comes to interop with non-nullity-annotated Java (library) code and there is no way for Kotlin users to fix it, but to go nullity-annotate said Java code.

Sure, community feedback is important. BTW, I'm now also doing community feedback. But the soundness of your type system is also important. Hence I think a switch or compiler plugin would be nice. Anyway, from the feedback I get here from other community members I get the general vibe that I stand alone in this and that I should just suck it up. Fair enough. I rest my case. Peace.

[hho]

I like the idea of such a switch - probably as a compiler flag. A lot of libraries have been improved since Kotlin 0.x tried this (e.g. Spring has annotated pretty much everything nullable or not-null) and there are also more Kotlin libraries available, so I think it might be more viable today than it was back then. However, a KEEP would be for stuff inside the language. So I think for a compiler switch, a feature request in YouTrack would be more appropriate.
EDIT: Somebody has already made one https://youtrack.jetbrains.com/issue/KT-72083

[Cies]

@hho Thanks for finding this! I've added my points to this conversation there and added a link to the conversation here. Now we need votes! So anyone reading this and agreeing: please vote!