This all looks great to me, except see one comment below.
—Guy
> On Mar 14, 2018, at 10:55 AM, Brian Goetz <brian.go...@oracle.com> wrote:
>
> Let me summarize what we're proposing for record constructors.
> . . .
>
> We can protect against double-initialization either by (a) not allowing the
> user to explicitly initialize fields corresponding to Ak+1..An, or (b) if the
> corresponding field is definitely initialized by the explicit constructor
> body, leave it out of the implicit initialization code.
If we go with choice (b), I would recommend that it be amended to read:
(b) If the corresponding field is definitely initialized by the explicit
constructor body, leave it out of the implicit initialization code;
if the corresponding field is definitely not initialized by the explicit
constructor body, put it in the implicit initialization code;
and in all other cases it is a compile-time error.
This is to defend against code such as
record Point(int x, int y) {
Point {
if (x > 0) this.y = x;
}
}
where if you put in the implicit “this.y = y;” then the user’s code "if (x > 0)
this.y = x;” has no effect, and if you don’t put it in then this.y might not be
initialized at all.
The user really should have written
record Point(int x, int y) {
Point {
if (x > 0) y = x;
}
}
and the compile-time error might be enough to wake him up to this fact.
