https://kotlinlang.org logo
#announcements
Title
# announcements
i

ilya.gorbunov

05/28/2017, 3:37 PM
@kevinmost With generics involved it's no longer a matter of one extra character.
o

okkero

05/28/2017, 6:12 PM
ilya.gorbunov: Can I get an example of how involving generics makes null handling different?
s

snrostov

05/28/2017, 8:12 PM
For example
Map<String, Integer>
can be one of:
Copy code
Map<String?, Integer>
Map<String, Integer?>
Map<String?, Integer?>
Map<String?, Integer>?
Map<String, Integer?>?
Map<String?, Integer?>?
When you use java's
Map<String, Integer> x
you can't use it as
Map<String, Integer?>
for example . And
x!!
is not worked here. Every time you need a cast
x as Map<String, Integer?>
...
☝️ 1
o

okkero

05/28/2017, 8:45 PM
With the above suggested compiler flag, x (if it came from Java) would be a
Map<String?, Integer?>?
in Kotlin, unless otherwise annotated in Java...
I don't see how I'd have to explicitly cast...
i

ilya.gorbunov

05/28/2017, 8:57 PM
You'd have to cast it when you pass it where
Map<String, Int>
is expected
o

okkero

05/28/2017, 9:16 PM
Well, that wouldn't be safe at all, would it? In that situation you should instead first make sure that the map itself isn't null, and then go through the map and make sure no values are null. Which I believe there are built in functions to help with (?). And this is true even without the proposed flag, if you want to be type safe...
Surely, for those of us who want to be absolutely null-safe and eliminate every possibility of shooting oneself in the leg, making all platform types nullable by default would only be a step in the right direction. Now, I realise not everyone agrees, which is why I suggested an opt-in compiler flag for this...