type variables from enclosing types?

Stephan Herrmann stephan.herrmann at berlin.de
Sat Dec 7 16:10:16 PST 2013

On 12/06/2013 07:50 PM, Dan Smith wrote:
> - A good way to observe inference behavior _without_ influencing the results is to invoke a method of the result rather than assigning it. (E.g., 'genericMethod(arg).foo()'.)

Thanks, yes this pattern helps to better test without cheating.

>> 4) I made experiments with pulling E into the inference
>> by augmenting 18.2.3 bullet 5.2: I added corresponding
>> constraints also for the type variables of enclosing types
>> of C<A1, ..., An> and C<B1, ..., Bn>. This directed the
>> inference into the expected solution,
> Yep, that's the right approach.  The 5.2 bullet is meant to cover this case, too.

I take your word for it, because I don't see this at all in the existing text.

>> but then it caused
>> regressions in situations of nested diamonds like
>>   new <>Outer.<>Inner()
>>   new <X>Outer.<>Inner()
>> I haven't yet analyzed the details of these regressions,
>> though.
> Looks like an implementation detail to fix.  That's clearly a syntax error in the JLS.  (As is new Outer<>.Inner().)

Sorry for the outrageous typos. The most interesting case looks like this:
    X<String>.Y<String> x2 = new X<String>().new Y<>("","");

(cf. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7046778 :)

After your confirmation I took on the challenge to debug this
and found&fixed the bug in our implementation.

BTW: finding a solution for
   X<String>.Y<String> x2 = new X<>().new Y<>("","");
seems to be out of scope for Java 8 type inference, right?


More information about the lambda-spec-experts mailing list