RFR: 8204610: Compiler confused by parenthesized "this" in final fields assignments

[Alex Buckley]

Qualified-`this` is a fair point to raise, but it's not obvious to me 
that we should go there.

JLS1 was deliberate in limiting the DU/DA and forward-field analyses to 
simple names -- big payoff for little cost. Many years later, with lots 
of people having "discovered" that `this.x` slipped through the DU/DA 
net, it seemed reasonable to catch that too. After all, it's just two 
terms with a separator, how hard could it be to implement? Well, it 
turns out that javac got a little tripped up by parentheses, so the 
answer is "Harder than you would think."

With qualified-`this`, the door is open to a blank final access with an 
arbitrary number of terms -- `int y = 
com.foo.bar.quux.outer.red.inner.green.this.x + 1;`. You might say, 
"This code is idiotic. More than any other code, its diversionary 
tactics need to be stopped." But we are now a long way from catching 
`int y = x + 1;`, and we're bound to tickle more compiler bugs around 
qualified names.

All that said, if you can count the qualified-`this` names used in your 
codebase to (i, RHS) access a variable's value, and (ii, LHS) denote the 
variable to assign to, then it would be interesting info.

Alex

On 6/11/2018 12:56 PM, Liam Miller-Cushon wrote:
> Where does qualified 'this' fit in here (e.g. `TypeName.this.x = 1`)?
> Should it be handled similarly?
>
> Related: JDK-8193904
>
> On Mon, Jun 11, 2018 at 12:43 PM Alex Buckley <alex.buckley at oracle.com
> <mailto:alex.buckley at oracle.com>> wrote:
>
>     A finger-in-the-air guess the impact of this source-incompatible
>     change:
>     1/4 the impact of banning `_` as a variable name.
>
>
> I'd be happy to help measure the impact of that change once there's a
> prototype.