[rvcdbn]

IMO there really needs to be a way to mark all variables non-null by default at package or at least a file level. Otherwise there will be a strong safety argument for always using T! syntax on almost every variable and this will just be a lot of noise.

[rileymichael]

Under "other possible future enhancements":

> Providing a mechanism in the language to assert that all types in a certain context are implicitly null-restricted, without requiring the programmer to use explicit ! symbols.

[foolfoolz]

i don’t think it will be that bad. we have a standard in our projects today that all java variables in code we own are not null. if you would like to have a nullable variable, you must annotate it with @Null

this is only an issue at the boundaries of our code where we interact with libraries. i imagine that will be the case with this new syntax as well

[jayd16]

If I understand you, then you're not getting any compiler check support for misuses, correct?

[lolinder]

I have to assume they have a lint rule for that.

With good tooling compiler error vs lint error is a distinction that matters about as much in practice as parse error vs type error—your editor and CI pipelines will yell at you either way.

[jayd16]

I suppose an aggressive linter could assume unmarked should be treated as non-null and at least demand nullability markup where needed.