Final issues regarding records

[Brian Goetz]

>> #1. Accessibility of various record members.

Let’s write down the various (competing) considerations here:

 - Consistency with precedent of default constructors.  When the compiler fills in a default no-arg constructor in a class that has no constructors, the default constructor gets the accessibility of the class.  
 - Consistency between mandated members.  It seems nominally simpler to have all the mandated members have the same accessibility.
 - Consistency between class and member accessibility.  It seems weird if a class is private but its constructor is public.  
 - Consistency between members mandated by record and members inherited from interfaces (as Gavin’s example illustrates.)

Note that all of these can be cast as “for consistency” arguments.  And you all know what i think of “for consistency” arguments.  And this set (and possibly others) illustrates the swan song of consistency: in a complex system, one can find consistency precedent for nearly anything.  

Observation: users will “override" the constructor much, much more often than accessors; to the extent we get the rules wrong regarding accessibility, rules regarding constructor accessibility will bite much more often.  While few developers are likely to even know the rule for default constructors, they will surely be surprised to have to write a public constructor in a private class.  

The reality here is that every category of mandated member(ctor, accessor, equals/hashCode) are in a different bucket regarding accessibility.  For equals/hashCode, these are forced moves — they must be public.  I think the “consistent with default constructors” rule for constructors makes the most sense, not because of consistency, but because of user intuition — this is likely what they are going to type first.  But accessors are in their own weird new world.  

I think (3) — make them public, as if they were specified by a hidden interface — is probably the least bad choice here.  

> 

> Co-op @Overrride.

Agree on this as well.  I don’t think having a separate thing helps anyone, nor does having no way to capture this intent.  

It will be a little weird that you can “override” a constructor now, but that will only likely be weird for a few minutes.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20200406/b43ff17d/attachment.htm>