This reads harsher than I intended, due to me efforts to be brief. So let me elaborate a little:
> On Mar 28, 2018, at 5:47 PM, Dan Smith <daniel.sm...@oracle.com> wrote: > >> On Mar 20, 2018, at 8:15 AM, Brian Goetz <brian.go...@oracle.com >> <mailto:brian.go...@oracle.com>> wrote: >> >>> >>> So add all this up and we have three kind of finalness for fields: >>> >>> - by default mutable, but you can change it >>> - by default final, and you can't change it >>> - (and now) by default final, but you can change it >>> >>> This seems like quite a bad situation to me. >>> >> >> I think what you are really saying here is: if you want immutable records, >> wait for value records, don't try to cram them in early? Then a record >> inherits the finality of the class kind that it is describing. And same >> with field accessibility. > > Value records don't support recursion, so are useless for many applications. > > The sweet spot for records is immutable fields of any type. If the way to > express that is to repeat "final" a bunch of times in the declaration, we > will have failed. To define "failed" more clearly: sure people will still use Java, they'll happily use the feature, things will be fine. But we'll be asking every record user to pay a tax (a handful of of "final" keywords) to accommodate the few weirdos who want mutable records. Underlying this is my expectation that most record declarations will be short (many one-liners), and most will not need mutable fields. The "non-final" keyword is a reasonable way to solve this problem without asking everyone to pay a tax. But Kevin's critique is also reasonable. > It's a fair point that we are comfortable with "implicitly always final", but > "final by default" is a new thing. And if there's a way to describe > record-like things that have mutable fields without a 'non-final' keyword, > great. But I think we need to spell those things using something other than > "record Foo(int x, int y)". What else could we do? Don't take these random ideas too seriously, but: maybe the declaration is a "mutable record"? Or just a "class", with some other signal that many record-like features are relevant? Or maybe the mutable fields appear in a different context? I feel like we could probably come up with something reasonable if we felt that final by default with a "non-final" opt-in is too confusing. —Dan
