Cies11/08/2023, 4:28 PM
) can be used in Kotlin like a not nullable type (
) but actually is nullable (like
). 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).
xoangon11/08/2023, 10:36 PM
and the Kotlin compiler will properly infer the type
Cies11/09/2023, 8:28 AM
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.
xoangon11/09/2023, 8:35 AM
bod11/09/2023, 8:38 AM
Cies11/10/2023, 12:53 PM
CLOVIS11/13/2023, 2:03 PM
everywhere), but you cannot pass it to another function, add it as a class attribute, etc, so the impacted area is kept small
Cies11/13/2023, 2:49 PM
everywhere This is exactly what I think is more correct! Add
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:
= pass along,
= huston we've got a default.
CLOVIS11/13/2023, 2:56 PM
If could be all over the placeWell, 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.
Cies11/13/2023, 5:22 PM
CLOVIS11/13/2023, 8:22 PM
Cies11/14/2023, 10:00 AM
CLOVIS11/14/2023, 1:36 PM
Cies11/23/2023, 8:55 AM