New candidate JEP: 468: Derived Record Creation (Preview)

[Brian Goetz]

> So, my conclusion is that compile time error is a far more preferable behavior over shadowing.

I can see how this would be an attractive idea, but its not practical.  I think this idea rests on some assumptions that are not true, that you can “just” rename a conflicting local out of the way, and secondarily that in the event that a record component is shadowed, you can “just” access it via the record.  The first is simply not true; we’ll come back for the second in a bit.  

Suppose I have some records:

     record A(int x, B b) { }
     record B(int x) { }

     A a = …
     a = a with { b with { x = 3; } }

In the outer reconstruction block, we have component variables x and b; in the inner block, we have a component variable x that shadows the outer x.  Neither of these can be renamed “out of the way”.  Under your proposal, we wouldn’t be able to use nested reconstruction on A at all, which is pretty bad.  

A similar example is:

    record Person(String name, Person parent) { }

I think these examples shows that “just make it an error” is a non-starter.  

As to “require re-access through the record”, this is a bad road to go down.  It is highly error-prone, since you now have two ways to access the same logical thing, but they’re not the same actual thing — one’s a copy, and it might have been mutated since copying.  So accessing the original in this context would be questionable.  And further, when we extent reconstruction to classes as well as records, the “I can just get it from the record” claim becomes no longer true.  

We didn’t decide to relax the shadowing rules here out of whim; these names _must_ be accessible because they are fixed by the record declaration.