> On Apr 24, 2020, at 3:08 PM, Brian Goetz <brian.go...@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
