on implementing state components as a first class concept

[Brian Goetz]

On 4/26/2019 2:04 PM, Joe Darcy wrote:
>
> so I thought a more prominent existence for "state component" as 
> opposed to "just a private field" was called for. It would also be 
> possible to do more or less what the implementation does now where the 
> fields are marked with a kind of STATE_COMPONENT rather than FIELD. 
> The conceptual question is then are the state components just fields 
> with special handling or are they something that gets turned into 
> fields (and methods and parameters...)? If they are just fields, the 
> STATE_COMPONENT kind is still needed and the method on TypeElement 
> could be dropped. Especially when reading a record from a class file, 
> I think some indication will be needed state component versus normal 
> instance field since I would suspect compilers (and potentially 
> programmers at some point) will find a need for instance fields beyond 
> just the state components. 

Semantically, a record

     record R(int x) { }

has _both_ an instance field called 'x' (which is private, and can be 
referenced from the body of the class), and a state component called 
'x', and these are not the same thing.  The state component does not 
intrude directly on the programming model, but should be captured in the 
class file (so we know we are compiling against a record), and exposed 
reflectively (so you know that a class is a record and not just a class 
that happens to have some fields and accessors.)  Record-ness is 
semantic, so it should be reflected as such.