Records -- current status

[Brian Goetz]

In any case, I think we've wedged ourselves pretty deep into a rathole.  
We're now simultaneously discussing:
  - whether records should support mutability at all
  - if so, what semantic differences might mutable records have, if any
  - if so, do we want to nudge towards immutability?
    - is it OK to have different defaults for records as for classes?
- where to put mutability annotations
  - what keywords should be used

Clearly that's a lot to cover at once.  Can we set the syntax issues 
aside until the first two are in hand?

Let's roll back to my mail of 3/23 where I talked about why we're going 
to be screwed if we don't engage mutability constructively...


On 3/29/2018 5:15 PM, Brian Goetz wrote:
> The idea of factoring out the defaults somewhere close by isn't 
> intrinsically objectionable (though the suggestion to factor them all 
> the way into the module descriptor is horrible), but it makes me 
> unhappy for a different reason -- it creates the impression that there 
> are two kinds of records, mutable and regular, with separate 
> semantics.  That creates a proliferation of new concepts in the users 
> mind, and worse, in ours -- which makes it more likely the semantics 
> of mutable vs plain records will diverge eventually.  A modifier on 
> the field, on the other hand, is something the user already 
> understands, especially when it is something as self-explanatory as 
> `mutable` or `nonfinal` or `non-final`.
>
> I would like it to be clear that there is one kind of record. (Ideally 
> it deals well enough with both final and nonfinal fields, perhaps 
> favoring one over the other.)
>
> On the topic of how to spell "non-final", let's keep these in mind:
>  - There *will* be other negation keywords coming.  So a regularized 
> way to express it makes future decisions easier and reduces the 
> perceived cost of new keywords that are just the negation of old 
> keywords.
>  - It may be tempting to spell it "mutable", but that only describes 
> one meaning of final, and wouldn't do well for the others (final 
> classes and final methods.)
>
> (FWIW, non-final is considerably *easier* for the parser to handle 
> than "nonfinal" -- because "-" is already a token and "final" is 
> already a keyword.  Depending on where in the grammar a new contextual 
> keyword is allowed, one may have to jump through unpleasant hoops.  
> But non-final poses relatively little problem, at least for our 
> compiler.  This is a strong point in favor of the non-keyword scheme.)
>
>
> On 3/29/2018 4:59 PM, Kevin Bourrillion wrote:
>> 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.
>