You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Explicit nulls is great and even though you can use .nn and even though unsafeNulls might be coming, some methods in Java classes like File or String that are used in Scala all the time should have a list of trusted (maybe hard-coded) methods that are trusted to not return UncheckedNull. For example, I think there is no instance where calling join, split, substring, trim etc. on Strings with non-null parameters (non-null parameters also not being part of a use-case of the method either) could return null and having to use workarounds that "feel" unsafe when you can be sure that they are safe on methods that you would use all the time is a little cumbersome and makes the code look messy when it shouldn't be.
The text was updated successfully, but these errors were encountered:
Explicit nulls is great and even though you can use
.nn
and even thoughunsafeNulls
might be coming, some methods in Java classes likeFile
orString
that are used in Scala all the time should have a list of trusted (maybe hard-coded) methods that are trusted to not returnUncheckedNull
. For example, I think there is no instance where callingjoin
,split
,substring
,trim
etc. on Strings with non-null parameters (non-null parameters also not being part of a use-case of the method either) could return null and having to use workarounds that "feel" unsafe when you can be sure that they are safe on methods that you would use all the time is a little cumbersome and makes the code look messy when it shouldn't be.The text was updated successfully, but these errors were encountered: