<div dir="ltr">I hope we would be very reluctant to start introducing keywords that contain punctuation ("non-final"). it's never been done and would likely confuse any number of tools for a while.<div><br></div><div>I somewhat like (gut-level) the idea of a single modifier on the record itself that reverses the default for all the fields at once... it emphasizes that the entire thing is becoming a mutable record, even if you put final back onto some of the fields.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 29, 2018 at 11:39 AM, Brian Goetz <span dir="ltr"><<a href="mailto:brian.goetz@oracle.com" target="_blank">brian.goetz@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br>
<br>
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.<br>
</blockquote>
<br></span>
I'm OK with finding other ways to do this than "non-final", though I think its quite likely that the "non-*" convention will muscle its way in at some point anyway (to name one example, classes that would be sealed by default will need a way to say "not sealed"), so I don't want to put too much stock in keyword-sticker-shock-avoidanc<wbr>e.  (I actually think non-final is a pretty good answer here; no one will be confused the first time they see it (they'll just bikeshed that it should have been spelled μtable" or something like that.))<br>
<br>
I'm less OK with saying "let's do immutable records now, and then figure out the mutability story."<br>
<br>
While some of the goodies for records will eventually filter down in some form to classes (e.g., better ways to fill in the obvious defaults in constructors, better ways to declare equals/hashCode), I also don't really want to count on that; I'd like to do a complete record feature and then select the bits we want to transplant to classes.<br>
<br>
I guess the question that this particular sub-thread is looking for an answer to is, which we dislike less: having to say final a lot, or having a new and different default for mutability of record fields.  (Or something else.)<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div style="line-height:1.5em;padding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif"><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(213,15,37);padding-top:2px;margin-top:2px">Kevin Bourrillion |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(51,105,232);padding-top:2px;margin-top:2px"> Java Librarian |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2px"> Google, Inc. |</span><span style="border-width:2px 0px 0px;border-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px"> <a href="mailto:kevinb@google.com" target="_blank">kevinb@google.com</a></span></div></div></div></div></div></div></div>
</div>