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