Updated Draft specs for JEP 359 (Records)

[Gavin Bierman]

Thanks Maurizio

> On 31 Oct 2019, at 14:29, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> Related to the earlier discussion on forbidden record members - how is this section still relevant?
> 
> "It is a compile-time error for a record declaration to declare a record component with the name clone, finalize, getClass, hashCode, notify, notifyAll, readObjectNoData, readResolve, serialPersistentFields, serialVersionUID, toString, wait, or writeReplace."
> 
> Chris says that the serialization spec ignores all the serialization-related methods if they appear inside a record; should we lift the restrictions?

Yes, we’re going to update this part of the spec. I will write separately about this.

> 
> In the grammar for records, I find it odd that we basically say that record members are class members plus compact constructor, but then we revert to say that instance initializer are not allowed.
> I wonder if a more specific production for the record body would be useful and more direct here?

I think this is a style thing, but I’m keen to reuse the class grammar. 

> 
> I note an asymmetry between the rules for canonical constructor and compact constructor; in one we say:
> 
> "Every field corresponding to a record component of R must be definitely assigned and moreover not definitely unassigned (16.9) at the end of the body of the canonical constructor."
> 
> In the other we say:
> 
> "It is a compile-time error if at the end of the body of the compact constructor, any of the fields corresponding to the record components of R are neither definitely assigned nor definitely unassigned.”

Indeed. Although I can remove both as we get this by virtue of the fields being blank final instance variables (JLS 8.3.1.2). 

> 
> Moreover, a deeper question: should we leave the magic auto-initialization of fields only for the compact form? That way, you would have a _new_ linguistic form, with _new_ properties, whereas old forms (e.g. a constructor with parameters) will have same rules as before (can have returns, must initialize fields explicitly). I think that, from a pedagogical aspect, that would be preferrable.

That’s what we do.

Thanks,
Gavin