<@U0CD02F9P> With generics involved it's no longer...

# announcements

[ilya.gorbunov]

@kevinmost With generics involved it's no longer a matter of one extra character.

[okkero]

ilya.gorbunov: Can I get an example of how involving generics makes null handling different?

[snrostov]

For example Map<String, Integer> can be one of:

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

[okkero]

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

[okkero]

I don't see how I'd have to explicitly cast...

[ilya.gorbunov]

You'd have to cast it when you pass it where Map<String, Int> is expected

[okkero]

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

[okkero]

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