brian.goetz at oracle.com
Thu Nov 2 15:05:33 UTC 2017
> In the proposal, you discuss about adding keywords like "non-final, unfinal, mutable", i.e. considering that there can be a different set of keywords for data class declaration which is different from the one we have on fields. In that spirit, we can have a flag like nullable, maybenull, etc to specify that the compiler will not generate a requireNonNull inside the principal constructor and that equals or hashCode do not need nullchecks.
Not really a fair comparison. The keywords suggested like "non-final"
are not adding new concepts; they are merely making explicit something
that was previously implicit. They are more akin to allowing the
"package" keyword to describe the default accessibility of class fields,
rather than a new feature. Non-nullability, on the other hand, is indeed
a new feature. And, it is not a simple property of fields (well, it
could be, but I suspect users would find that to an unsatisfying
interpretation of "support for non-nullity.")
Ignoring that, what I think you're saying is "You don't need to do
full-blown nullity propagation, you could simply have an 'annotation'
that triggers a null check on data class constructors." And if that's
what you're saying, I agree, we could do that. But I suspect the
limitations of this would very quickly turn opinion negative. (Can't
use it on non-data classes. Can't use it on locals. Using it on
non-final fields starts to get messy fast -- do we have to do this on
all field writes? Etc.)
More information about the amber-spec-experts