I consider "platform types" to be a great tool for...

# k2-adopters

[Cies]

I consider "platform types" to be a great tool for Kotlin PR (it eases the on-ramp for those coming from Java) but totally evil from a nullability-should-be-in-the-typesystem perspective. Why? A platform type (say SomeType!) can be used in Kotlin like a not nullable type (SomeType) but actually is nullable (like SomeType?). So you think you are all good, but then shit blows up in your face with Kotlin's-version-of-Java's-NPE. Would it be possible to have a compiler flag or compiler plugin that makes all platform types nullable? It would be more honest and runtime-safe. And I care for those things (I had a fling with Haskell).

[xoangon]

You can annotate the types in other lenguages with @Nullable or @NotNull and the Kotlin compiler will properly infer the type

[Cies]

I know: but all our code is Kotlin already. I'd have to go over all 3rd party libraries! In TypeScript there's .d files by which one can add type info to libraries that lack them, but this is not possible for Kotlin afaik. I really think this behaviour should be made a compiler flag.

[xoangon]

I'm not aware of anythin like that in Kotlin 😕

[bod]

A compiler flag sounds like a cool idea to me! Treating them as non-nullable is still probably the best default to keep, to ease interop, but having the ability to change this per project would be nice.

[Cies]

The "best" default is when PR and easy-on-ramp are important. And I agree it's better not to change the default at this pint. Buttttt, when we measure by "correct" then it

[Cies]

's certainly not the best. 🙂

[CLOVIS]

That's why you can't create a variable of a platform type. If you call a function with unknown nullability, it's tolerated (otherwise you'd have to go !! everywhere), but you cannot pass it to another function, add it as a class attribute, etc, so the impacted area is kept small

[Cies]

@CLOVIS The impact area depends on how(often)/where you use Java libs w/o nullability annotations. If could be all over the place. Sure it'd be even worst allow us to created and bind platform types in Kotlin. But the request here is simple: for sake of correctness, should we not have the ability to make all plaformtypes nullable by default (instead of secretly nullable hidden inside a not-null type).

> otherwise you'd have to go !! everywhere
This is exactly what I think is more correct! Add !! and ? and ?: all over the place to mark the explicitly mark locations you bring a platform type into Kotlin-land AND it signals the way you want to resolve nulls: !! = boom, ? = pass along, ?: = huston we've got a default.

[CLOVIS]

If could be all over the place

Well, not really. It cannot be in function parameters, it cannot be in function return types, it cannot be in class attributes. The only place it can happen is in local variables inside a function, and that's only if you don't annotate it with a type yourself. If you enable inlay hints, the IDE even shows you exactly which local variables are "dangerous" and which aren't, and there's an ALT-ENTER helper to declare the type explicitly to avoid platform types altogether.

[Cies]

Sorry "*it* could be all over the place". What I meant is that any place I call a Java lib thing it may return a sneaky platform type. I have looked into "inlay hints", but cannot see how this can visually distinguish platform types for me. I just use a stock IntelliJ and "inlay hints platform types" does not yield much of value when searching online. thanks for chiming in, much appreciated.

[CLOVIS]

If you go into "File | Settings | Editor | Inlay Hints" and enable the inlay hint "Types | Kotlin | Local variable types", IntelliJ will display all inferred types. It makes platform types much easier to spot, so you're less likely to miss them.

In general, I recommend enabling most inlays.

[CLOVIS]

If you press alt+enter on the variable, you get an option to consider it nullable, and another to consider non-nullable. In both cases, it makes the decision explicit (what I understand to be your goal).

[Cies]

> it makes the decision explicit (what I understand to be your goal).
My goal is to make explicit the default: having to go through all code manually to find places where I have to make it more explicit it not going to work on a large codebase and a large team. Switching a compiler flag will result in lots of compile errors, but after fixing them the problem is gone.

Today I had an NPE in Kotlin code. A list of data classes in Kotlin contained null while according to the type it should not have. This happened because a method in Java lib received a lambda we wrote in Kotlin: that method in the Java lib erased the nullability. Grrr..

[CLOVIS]

I see. I'm not aware of any way to do this at a large scale currently.

[Cies]

I know it can be done with a compiler plugin, there's just no such compile plugin and with K2 (which we cannot use at the moment) around the corner I wait for a bit to take a stab at it myself 🙂