I think Guy's concern is that you could cause code to _read_ an
uninitialized, final field? Of course, we have this problem all over
the place today, so having it in records does not make things
significantly worse.
On 4/29/2020 2:47 PM, Dan Smith wrote:
On Apr 29, 2020, at 12:35 PM, Guy Steele <guy.ste...@oracle.com> wrote:
On Apr 29, 2020, at 2:23 PM, Dan Smith <daniel.sm...@oracle.com> wrote:
On Apr 29, 2020, at 11:28 AM, Guy Steele <guy.ste...@oracle.com> wrote:
Appealing, but it does raise the question of whether, if the programmer uses
some sneaky trick such as calling super, this can really be enforced ar compile
time on all cases. If it can (after all), then your proposed wording looks good
to me.
The idea would be to rely on the definition of "assign to" in JLS 16. That uses a heuristic that counts
"x =" or "this.x =" (and, in javac, but not currently specified properly, "(this).x",
etc.)
Stepping back: in general, it's illegal to assign to a final field. There's one
exception: inside a constructor, where the field is DU, using an assignment
that satisfies the heuristic. In any other case, you get an error.
So the language has carved out a small hole permitting assignments, and this
rule closes that hole.
That's all very good.
But I'm worried about cases where you use some escape catch such as calling super or a
static method, passing it "this" as an argument if necessary, and arriving at a
place where you need to solve the halting problem to decide at compile time whether the
forbidden behavior might occur. I haven't swapped all the current rules back into head
enough to decide for myself whether this sort of scenario can actually arise.
I'm leaning heavily on "in general, it's illegal to assign to a final field".
If you try to construct your exploit, you will find that when you try to assign to the
field, you'll get a "can't assign to final field" error.
