Thanks Maurizio > On 31 Oct 2019, at 14:29, Maurizio Cimadamore > <maurizio.cimadam...@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
