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.
