on implementing state components as a first class concept

[Brian Goetz]

>> 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.
>
> We discussed other ways to capture in the class file that a class is a 
> record: extending a common super class and / or adding an annotation 
> to all records. One, or both, of these options should be enough for 
> tools to know that they are dealing with a record. If additional 
> information should be captured about the state components, fine but 
> that information shouldn't probably determine if a given class is a 
> record or not

Extending a superclass should be enough to determine record-ness, but 
only if the language prohibits non-record classes from extending it. 
But, a superclass is not enough to capture the component metadata, and 
we dont' actually have any other need for a superclass, so we should 
probably drop it.  Similarly, annotations do not carry linguistic 
semantics.  So if we want a record to be something semantic, and not 
just a macro expansion, there should be a Record attribute in the 
classfile that captures everything about the record (such as names, 
annotations, and signatures of its components.)