"Chained" qualified instance creation expressions (diamond in qualifiers)

[Srikanth]

On Wednesday 06 May 2015 07:36 PM, Georgiy Rakov wrote:
> Hello,
>
> let's consider following example:
>
>     classD {}
>
>     classOuter2<Q> {
>          classOuter1<W> {
>              classFoo<T> { }
>          }
>     }
>
>     public classTest69 {
>
>          public static voidtest(String argv[]) {
>              Outer2<?superD>.Outer1<?superD>.Foo<?superD> f20 =newOuter2<>().newOuter1<>().newFoo<>() {
>                  privateOuter2<Object>.Outer1<Object>.Foo<D> simpleMethod1() {return this; }//compiles Ok
>                  //private Outer2<D>.Outer1<D>.Foo<D> simpleMethod2() { return this; } //causes compilation error
>              };
>          }
>     }
>
>
> JDK9b60 causes Q and W to be inferred as Object. This can be seen:
> - from the fact that code above compiles successfully;
> - from the fact that uncommenting the method above causes compilation 
> failure.
>
> So what we actually have is:
> - Q is inferred as Object;
> - W is inferred as Object;
> - T is inferred as D.
>
> However according to intuition it seems that Q and W should have been 
> inferred as D as it happens to T.
>
> I believe this corresponds to spec, the reasons presented below seem 
> to cause this:
>
> 1. Following assertion from JLS 18.5.2 is not applied when JLS 15.9.3 
> is applied to new Outer2<>() and new Outer1<>():
>
>     Otherwise, the constraint formula ‹Rθ→T› is reduced and
>     incorporated with B_2 .
>
> So for outer classes inference proceeds with no constraint formula 
> actually causing inference variable in question to be inferred as D.
>
> 2. JLS 15.9.3 doesn't use type parameters from outer classes when 
> processing new Foo<>(). Namely following assertion from JLS 15.9.3 
> doesn't mention type parameters from possible outer classes:
>
>     Let F_1 ...F_p be the type parameters of C, and let G_1 ...G_q be
>     the type parameters (if any) of |c_j |.
>
> So constraint formula created by JLS 18.5.2 assertion presented above 
> engages just inference variable from Foo, i. e. T.
>
> However I believe more broad change of spec will be required to 
> implement this "intuition" than just modifying spec according to two 
> points above.
>
> So:
> 1. Could you please tell if I understand correctly that the fact that 
> Q is inferred as Object, W is inferred as Object really corresponds to 
> spec and it's not a JDK issue.

Hi Georgiy,

My original response is good enough for this part - The target type from 
the LHS i.e

Outer2<?superD>.Outer1<?superD>.Foo<?superD>

gets imposed on

newFoo<>() {  ... }

and the specification does not mandate/require/sanction/allow a 
qualified instance creation expression
to propagate the target type or any part thereof to any enclosing 
instance creation expression (qualified
or otherwise).

So Q and W being inferred as Object is the right behaviour per the 
current specification.

> 2. As for me it looks reasonable to enhance specification so that Q 
> and W would be inferred as D too. Could you please tell if you agree. 
> If you do would it be worth creating spec enhancement in Jira?

This part which have you described as being "intuitive", I'll request 
Dan Smith to answer the reasons for the state of the art - I don't 
readily know what canons of type system theory would require it to be
the way it is - i.e why would we not allow the qualified allocation 
expression to propagate suitable target types to the enclosing 
expressions - and whether this is something amenable to tinkering.

Thanks!
Srikanth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150508/4c5b6e5b/attachment.html>