4 ms·
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 argume
by rvcdbn 2y ago
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.
- foolfoolz 2y agoi 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 2y agoIf I understand you, then you're not getting any compiler check support for misuses, correct?
- lolinder 2y agoI 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 2y agoI suppose an aggressive linter could assume unmarked should be treated as non-null and at least demand nullability markup where needed.
- rileymichael 2y agoUnder "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.