Records -- current status

[Brian Goetz]

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