[records] Time to re-read JEP 359

[Brian Goetz]

On 1/4/2020 10:35 AM, Tagir Valeev wrote:
> Hello!
>
> I was watching a Twitch stream by Nicolai Parlog [1] who explored the
> records feature. Quite expectedly he did this reading JEP 359, rather
> than the spec draft. He noticed at least two inconsistencies:
>
> 1. The record's body may declare static methods, static fields, static
> initializers, constructors, instance methods, instance initializers,
> and nested types.
>
> "intance initializers" part should be removed, to match the spec draft.

Done.

> 2. Any of the members that are automatically derived from the state
> description can also be declared explicitly.
>
> private final fields that match the record components are members and
> derived from the state description, so from this statement, one could
> conclude that explicit field declaration is also possible (which is
> not an unreasonable thing to do: one may want to customize the field
> annotations). If we don't allow such a declaration, this statement
> should be refined (probably changing 'members' to 'methods and
> constructor' or 'members except field' or something like this).
>

This is a fair question; do we want to allow this?  There are several 
reasons one might want to do so:

  - Consistency (though this is generally the reason you give when you 
have no other reason), you can do it for the other members;
  - Maybe the author wants the fields public;
  - Maybe the author wants annnotations on the fields that, were they to 
be put on the components, would be spread to places where they are _not_ 
wanted.

The last of these is the only one that is mildly compelling here, but, I 
wonder whether this is purely theoretical, or whether someone actually 
needs this.

The reasons against include:

  - It is not likely to be something people want to do very often, and 
so the return on spec complexity here is probably negative.