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

[Ruckus]

> but I do mind that they are "treated as nonnull while they are certainly nullable"
What do you mean by this? What makes them "certainly nullable"? The whole point of platform types is that is isn't certain if they are nullable, which is how they are treated, not as nonnull. For example, you can do null checks and casting on platform types, whereas the compiler will complain they're not needed for nonnull types.

// nonnull
var a: String = ...
a.length  // okay
a?.length  // complains that ? is not needed

// nullable
var b: String? = ...
b.length  // error
b?.length  // okay

// platform
var c: String! = ...
c.length  // okay
c?.length  // okay

[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

[Ruckus]

> When it isn't certain that it nonnull, it should be treated as nullable.
I don't really agree with this, but that's likely just due to my personal experience (not being bitten as often/badly as you).

There are plenty of java libraries and frameworks that take great pains to handle nullability well and document it accordingly, and having to add a whole lot of useless null handling to my Kotlin code for that would be a terrible experience.

As far as "why not have a switch", that's could be nice. It could also require answering other (potentially harder) questions. For example:
• How does it apply?
◦ Is if for the entire codebase, or can you set it on a per-module or per-import level?
• What values does the switch have?
◦ You mentioned a warning example, but there are libraries that explicitly never use nulls at all, and instead use Java's Optional or something similar. Should the switch also have an option to treat all platform types as nonnull?
And probably others I can't think of off the top of my head. There's no reason not to ask them, it just might make the scope balloon a bit.

[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.

[Ruckus]

> this is called erring on the side of safety
Yes, but "erring on the side of safety" isn't some be-alll and end-all trump card. It's just one consideration of many. For example: "... feedback showed that it wasn't pragmatic ..." This is called erring on the side of a good user experience (or perhaps erring on the side of fun in Kotlin world 🙂).
> I understand this is not done for "an easy onramp" or for "marketing purposes"
No, as @Ben Woodworth explained, it was done due to community feedback, which is generally a pretty good reason. You are also providing community feedback, and I'm sure it will be considered along with all the rest.

[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.

[Ruckus]

Thank you, and peace to you as well

[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!