Data classes

[Brian Goetz]

> 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.)