peter.levart at gmail.com
Sun Oct 6 16:13:21 UTC 2019
Just thinking loud here...
On Wednesday, October 2, 2019 3:27:38 PM CEST Peter Levart wrote:
> 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
- 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
What do you think?
More information about the amber-spec-experts