instance initializer

[Maurizio Cimadamore]

Hi Peter,
we've been thinking more about this... as it was noted in this thread, 
perhaps the biggest value of 'lone' instance initializers is that they 
contain _common_ initialization code that is replicated across _all_ 
constructors. Do we need this for records? Probably no, we don't - the 
reason being that a record is a well-behaved construct that acts as a 
transparent wrapper for its state, with an equally well-defined way to 
construct it (the canonical constructor).

The way I see it, is that it is more a bug than a feature the fact that 
you can have 5 unrelated constructors on a record class - because one of 
the values behind opting for a record (vs. a class) in the first place, 
is to have control over the way in which record instances are created - 
which is in fact backed up by serialization as well (serialization 
guarantees that creation will always go through the canonical constructor).

So I think having a constructor that doesn't delegate to the canonical 
constructor is potentially dangerous, as it exposes an alternate way to 
construct a record which is not the _blessed_ one, might skip some of 
the invariant checks etc.

Let's say we demand that all secondary constructors starts off by 
delegating to the canonical constructor:

this(...)

If that's the case, then all initialization goes through the canonical 
constructor, which also means that the canonical constructor is also the 
code where you'd put the statements you otherwise would have put into an 
instance initializer.

In other words, we want alternate constructors to be used as a way of 
providing convenience overloads, as in this case:

record Point(int x, int y) {

     Point() { this(0, 0); }

}

I don't think there's anything to be gain by making secondary 
constructors more flexible as, by doing so, we would also lose an 
important invariant of record construction - that all record creation 
flows through the canonical constructor.

Therefore, I'd like to propose that:

* a secondary, non-canonical constructor must always start with 
this(...) (the target of the delegation might be another secondary 
constructor, but you will eventually reach the canonical one)
* instance initializers on records are banned

Maurizio



On 06/10/2019 17:51, Peter Levart wrote:
> On Sunday, October 6, 2019 6:21:45 PM CEST Brian Goetz wrote:
>>> 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.
>> I would agree that instance initializers in records are mostly useless,
>> and keeping them around adds some complexity.  Any work that can be done
>> in an II could also be done in a compact ctor with about the same number
>> of keystrokes:
>>
>>       { ++instanceCount; }
>>
>> vs
>>
>>      Foo { ++instanceCount; }
>>
>> The argument for keeping them is to minimize the number of gratuitous
>> differences between records and classes.  But, "it is a compile-time
>> error for a record class to have an instance initializer" is a pretty
>> simple spec change... and probably no one will notice.
> I know that making special rules in record constructors (about being able to
> access instance fields) is also increasing the number of gratuitous
> differences between records and classes, but in order to ban instance
> initializers, there has to be a an alternative way to specify initializing
> code that is always executed. Perhaps it is enough just to suggest users to
> put such code into canonical constructor and always call that constructor from
> other constructors as opposed to forcing them to do that with language
> constraints.
>
> Regards, Peter
>
>
>