type variables from enclosing types?
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,
> 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