Records -- current status

[Dan Smith]

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.smith at oracle.com> wrote:
> 
>> On Mar 20, 2018, at 8:15 AM, Brian Goetz <brian.goetz at oracle.com <mailto:brian.goetz at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180329/198e61ba/attachment.html>