Possible records tweak

[Dan Smith]

> On Apr 24, 2020, at 3:34 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Apr 24, 2020, at 12:43 PM, Dan Smith <daniel.smith at oracle.com> wrote:
>> 
>>> On Apr 24, 2020, at 1:32 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>> 
>>>> (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.)
>>>> 
>>> accessing to the identity hashcode or the current class inside a constructor is valid (i believe) but those are a corner cases.
>>> 
>> 
>> Ah, yes. This generalizes to calling methods that safely operate on an already-initialized superclass (typically instance methods of the superclass).
>> 
>> If we someday have abstract records or other forms of user-defined superclasses, it will be quite reasonable to call the superclass's instance methods from the subclass's constructor.
>> 
> 
> So maybe `super` is DA but `this` is DU, just like in the code
> before the super-constructor call.  (I’m abusing the terms DA/DU
> like Brian is, and you call out, but they are close to correct.)

I think this means I can't call inherited method 'getParentWidget()' or some static utility 'computeWidgetOfParent(this)' method (e.g., 'identityHashCode(this)'). I *can* call 'super.getParentWidget()'.

It's a do-able way to apply some discipline. Feels a little heavy on the "you can't do that" side and light on the "we'll guarantee better programs" side—because of course, once you've called the super method, it can do whatever it wants with the object.

Overall, my sense is that controlling all accesses of 'this' (explicit and implicit) is more ambitious than we really want/need here. Airtight constructors are a problem for another day. Prohibiting assignment to the instance fields is more manageable.