Draft Spec for Second Preview of Flexible Constructor Bodies (JEP 482)

[Maurizio Cimadamore]

>
> Here's a better one. Attr.java line 617 refers to the instance field 
> Attr.chk 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java*L617__;Iw!!ACWV5N9M2RV99hQ!Nrp50rInAZLa1ZhfKP2Fy85X9kCKR3tS3qLArQ6AFctCiIvw6Psd7E-IbS4aduRMHcEspgdkvdkxQsk5A-swI5l1UVvDCQ$> 
> from anonymous inner class RecoveryInfo.Check.NestedCheckContext$1 
> which is declared in a super() parameter in the RecoveryInfo() 
> constructor.
>
> If that anonymous inner class had no outer instances, then wouldn't it 
> be unable to access Attr.this.chk ?

I know that example. In fact that’s the only example I could find that 
was similar to the cases we discussed. The JDK has other 8 class 
declarations in a pre-construction context, but they have /no available 
/ enclosing instance, because are something like:

|class Toplevel { Toplevel() { this(new Object() { ... }); } } |

So, back to Attr - turns out that this code (of which I’m not very proud 
of :-) ), can be rewritted w/o accessing chk.basicHandler inside the 
anon class. In fact, we are passing chk.basicHandler to the anon 
constructor, and that value is made available through the inherited 
“encl” field. So, if we replace |chk.basicHandler| with |encl|, this 
class becomes “well-behaved” again. Which suggests a possible tactic for 
dealing with issues such as this: the class that creates the local anon 
class has access to the outer this, and can pass them as constructor 
arguments.

> I want to make sure I'm not misunderstanding your proposal.  When you 
> say "treat all class declarations in pre-construction context as 
> having no enclosing instance" I still read the phrase "enclosing 
> instance" as potentially ambiguous (does that include "2nd enclosing 
> instance"? Etc.).
>
> But previously you said: "Wouldn't it be easier to say that every 
> class declared in a pre-construction context is static, period, and 
> cannot reference anything from enclosing contexts?" so I'll assume 
> that's what you mean.

Yes, I meant that /no enclosing instance/ is available from a class 
declaration occurring in a pre-construction context. So your #2 below.

>
> So the two proposals we're talking about for when an outer class 
> instance expression "Foo.this" is invalid are:
>
>  1. "Foo.this" is invalid when the expression is contained in a Foo
>     early construction context (with any level of nesting) (this is
>     what the JEP proposes)
>  2. "Foo.this" is invalid when the expression is contained in /any/
>     early construction context (your proposal?)
>  3. Is there some other hybrid proposal?
>
> I'm not going to argue that #1 is the best in all possible worlds, but 
> I think #1 is better than #2, if only because #2 will cause real-world 
> code out there to start failing to compile - including javac itself.
>
>
I’m not worried much about the “code out there” which doesn’t really 
seem to have taken up on such idioms.

Thinking more, I think I can perhaps find an argument in defense of the 
strategy of the approach outlined in the current JEP: migrating lambdas 
to classes.

So, back to your example:

|class Outer int x; class Inner extends Foo { Inner() { super(new Bar() 
{ { Outer.this.x++; } // allowed??? }); } } } |

Let’s say we write this using lambdas:

|class Outer int x; class Inner extends Foo { Inner() { super(() -> { 
... Outer.this.x++ ... }); }); } } } |

This is now ok, as the lambda has access to any enclosing instances that 
were available at the time the lambda was created (e.g. Outer.this).

So, the best supporting argument I can find is that, by making the 
enclosing instance rules more precise, we can actually support a fuller 
migration between lambdas and local/anon classes. Now, such a migration 
is still not perfect, as lambdas and local classes have different 
meaning of |this| and |return|, so you still just can’t copy and paste 
code blindly and assume it will work. But, at least we wouldn’t be 
adding yet another asymmetry to the list.

Maurizio

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-experts/attachments/20240611/281895c3/attachment-0001.htm>