Records -- current status
Brian Goetz
brian.goetz at oracle.com
Thu Mar 29 21:39:21 UTC 2018
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.
>
More information about the amber-spec-experts
mailing list