Record construction

[Guy Steele]

This all looks great to me, except see one comment below.

—Guy

> On Mar 14, 2018, at 10:55 AM, Brian Goetz <brian.goetz at 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.