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

[Srikanth]

On Thursday 07 May 2015 06:10 PM, Srikanth wrote:
> I'll wait for Dan to chime in with chapter and verse, but I believe 
> 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).

Sorry, upon rereading your mail, I see that this is something you are 
acknowledging and
your question is broader. I'll study this in more detail tomorrow.

Srikanth
>
> 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.
>> 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?
>>
>> Thanks,
>> Georgiy.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150507/4de47356/attachment-0001.html>