On 2017-11-02T11:05:33 -0400 Brian Goetz <brian.go...@oracle.com> wrote:
> > 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.") I think it would be better to get non-nullability language-wide first as a separate feature. -- Mark Raynsford | http://www.io7m.com
