instance initializer

[Peter Levart]

Hi,

Just thinking loud here...

On Wednesday, October 2, 2019 3:27:38 PM CEST Peter Levart wrote:
> Hi,
> 
> On 9/6/19 2:54 AM, Brian Goetz wrote:
> > In that case, what we would see is that on exit, neither i nor j were
> > either DA or DU, and we would issue a compiler error.  For each field,
> > there are three possibilities:
> > 
> >  - The field is DU on all paths out of the ctor; we initialize it from
> > the corresponding parameter.
> >  - The field is DA on all paths out of the ctor; we do nothing.
> >  - The field is neither DU nor DA on some path out of the ctor; error.
> > 
> > We could extend this analysis to the init block, where if its either
> > of the first two cases, we feed that information back into the ctor
> > analysis, and always error in the third case -- the real question is
> > whether its worth the bother.
> 
> Isn't similar thing already in place for final fields? They have to be
> DA. Granted this implementation would have to be tweaked because
> generated code would depend on the outcome of the analysis. Remi's
> concern that the analysis would have to work on user code + generated
> code is perhaps unfounded. The analysis would have to work on user code
> only and the outcome would then be used to generate the automatic code.
> 
> I think John is proposing a runtime workarround: user code playing with
> constructor parameters (locals) before assigning them to the fields. In
> this case all fields would be guaranteed DA at the end. But that doesn't
> account for instance initializer block(s) as they don't have the
> constructor parameters in scope.
> 

Instance initializers don't play well in records. Why?

They don't play well with the notion of canonical constructor. Records mandate 
two things among others:
- formal parameters of a mandatory canonical constructor
- instance fields

You can't skip a field and you can't add one. You can't skip a parameter of 
the canonical constructor and you can't add one. Both of them are always in 
sync with the declared record components.

What is the purpose of instance initializer? (Partly) initializing the state 
of the object. So to have any meaning (besides side effects that do not 
pertain to instance state), instance initializer must set at least one 
instance field. If it does set it, then what is the purpose of a mandatory 
canonical constructor parameter that relates to that field? It must be 
ignored. Not very sensible.

So I was thinking about some constraints that would still allow everything 
except insensible things:

- do allow to override implicit canonical constructor with classical 
constructor having exact number, types and order of parameters as the declared 
record components. Rules in such constructor are unchanged.
- do allow to override implicit canonical constructor with compact 
constructor, but don't allow access to instance fields in the compact 
constructor.
- allow other constructors besides canonical constructor, but don't allow 
access to instance fields inside them from code where the record instance is 
not "Definitely Initialized". Make it compile time error if record instance is 
not "Definitely Initialized" in all normal exit paths from the constructor.

What does it mean for record instance to be "Definitely Initialized" or DI? 
Record instance is DI if all its instance fields are DA. How do we achieve DI 
in all normal exit paths from the record constructors if access to fields 
inside constructor is not allowed until the instance is DI? In classical 
canonical constructor, this is achieved classically. In compact canonical 
constructor, this is achieved by automatic assignment of all constructor 
parameters to instance fields at all normal exit paths from the constructor. 
In other constructors this is achieved by chaining to some other (possibly 
canonical) constructor, i.e. calling: this(....);

In these scheme, canonical constructor also acts as instance initializer, 
since it is always called from other constructors. Classical instance 
initializer is therefore not needed any more and could be prohibited in record 
types.

What do you think?

Regards, Peter