> 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.
