3 ms·

Thanks for the downvote. Let's close this discussion.

• the_af 10y ago
  I didn't downvote you. In fact, I consider your post interesting, because (for example) I didn't know about the opt-in nullable references. Here's a +1 to counter the downvote.
  • airless_bar 10y ago
    Alright. Sorry. Regarding your question about nulls and Java: I think that there is not much Scala can do here. All existing evidence from other languages that tried this shows that there is a large semantic gap between "nullable values" and "values of unknown nullability". As Scala is much more independent of Java it is a much smaller issue, but improvements with Java interop require action from Java library authors first. The approach of supplying external nullability meta data has largely been a failure, because a) authors are not aware of the stated, external constraints, so they could break these assumptions in future releases without even knowing b) it's really really hard to retrofit nullability guarantees into libraries which have been designed without this requirement in mind c) the existing ecosystem is not very amenable to these guarantees, as nullability metadata would be largely limited to final classes and members, because everything else could be subclasses or overridden in third-party code, breaking these assumptions As soon as Java library authors themselves start using @Nullable/@NonNullable annotations everywhere, there is a good opportunity of reading these annotations and typing the values accordingly, but without it, benefits are very slim. The planned changes are valuable for dealing with nullable types, but as mentioned "unknown nullability" needs a different solution, and I think it's currently not worth adding something to the languages as long as there is still hope for widespread adoption of nullability annotations.