I've always assumed that, eventually, if we wanted too, we could always spell 
it as

      !final

That also makes possible such explicit declarations as !volatile and !transient 
. . . And possibly even !null. 

      !final !null String x = "quux";  // mutable, but you can't set it to null

—Guy

Sent from my iPhone

> On Mar 29, 2018, at 2:39 PM, Brian Goetz <brian.go...@oracle.com> wrote:
> 
> 
>> 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.
> 
> 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-avoidance.  (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.))
> 
> I'm less OK with saying "let's do immutable records now, and then figure out 
> the mutability story."
> 
> 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.
> 
> 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.)
> 

Reply via email to