mark at io7m.com
Thu Nov 2 15:19:56 UTC 2017
On 2017-11-02T11:05:33 -0400
Brian Goetz <brian.goetz at 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
More information about the amber-spec-experts