Records -- current status

Dan Smith daniel.smith at
Wed Mar 28 23:47:50 UTC 2018

> On Mar 20, 2018, at 8:15 AM, Brian Goetz <brian.goetz at> 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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the amber-spec-experts mailing list