necessary information is never considered by inference?

[Dan Smith]

On Jan 31, 2014, at 5:39 PM, Dan Smith <daniel.smith at oracle.com> wrote:

> On Jan 28, 2014, at 4:33 AM, Stephan Herrmann <stephan.herrmann at berlin.de> wrote:
> 
>> Consider this example:
>> 
>> import java.util.stream.Stream;
>> import java.util.*;
>> import static java.util.stream.Collectors.collectingAndThen;
>> import static java.util.stream.Collectors.toList;
>> public class X {
>> 	void test(Stream<List<Integer>> stream) {
>> 		stream.collect(collectingAndThen(toList(), Collections::unmodifiableList))
>> 			.remove(0);
>> 	}
>> }
>> 
>> I fail to see anything in the spec that would let us determine the
>> return type of the collect(..) invocation. Hence the remove() call
>> would be unresolvable.
>> 
>> Given that javac does accept the program, I'm wondering what's causing
>> this discrepancy.
>> 
>> We have two inference variables from the outer invocation, let's write it as:
> 
> ...
> 
>> However, I don't see where the spec would allow me to introduce
>> such constraints: we're reducing this constraint:
>> ⟨collectingAndThen(toList(), Collections::unmodifiableList) → Collector<? super List<Integer>,A#1,R#0>⟩
>> for this reduction 18.2.1 instructs me to apply 18.5.2 for computing B3.
>> The problem is: computation of B3 only comprise those parts of 18.5.2 that
>> never touch the argument expressions, those come into the picture only after.
> 
> Yes, this is the crux of the problem.  The nested invocation's method reference is irrelevant to invocation typing in the spec, but javac is using it.  I believe javac captures the intended behavior; I'm now revisiting the design discussions about this to figure out what's supposed to happen.

See the bug tracker here:
https://bugs.openjdk.java.net/browse/JDK-8033488

The solution is simply to collect nested nested invocation arguments that were not pertinent to applicability when the set of remaining constraints, C, is assembled.  (We also need to collect 'throws' constraints from all nested arguments that are lambdas/method refs.)  Then they participate in the dependency analysis, just like everything else.

—Dan