Possible records tweak

[Guy Steele]

> On Apr 24, 2020, at 3:08 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> 
>> Not a bad idea, but here are two and a half alternatives we could consider:
>> 
>> (1) Simply ban use of “this” within a compact constructor.  This might seem like overkill, but it is very easy to explain: the keyword “this” is not available in a compact constructor, period.  Because the argument names shadow the field names, you don’t have access to the fields at all in a compact constructor.  If you don’t like it, write a non-compact constructor.
> 
> That's a nice clean way to do it, because under this (heh) model, `this` is useless -- can't read the fields (they're DU), can't write them (cause I say so), shouldn't call instance methods anyway (because the object is uninitilized and therefore may be in an invalid state), and you shouldn't pass `this` to alien code (because that undermines the final field guarantees of the JMM.)  So if its useless, just don't utter it.  
> 
> (Which, in hindsight, might have been a good rule for _all_ constructors, if there was another way to initialize the fields.  Surely would have eliminated much verifier complexity.)

This is the “if only” theory we could have had back in 1995:

	In any constructor, for every field not shadowed by a constructor argument, the constructor
	has an implicit local variable with the same name that is not initialized.  It is a compile-time
	error unless every such implicit local variable is definitely assigned on exit.  On exit, every
	field is assigned from the constructor argument or implicit local variable of the same name.
	The keyword “this” is not available in the bod of the constructor.

But I’m sure that back in those days such implicit local variables, and the storage consumption
they would imply, and even the extra assignment operations required, would have been anathema.

—Guy