necessary information is never considered by inference?

Dan Smith daniel.smith at oracle.com
Fri Jan 31 16:39:47 PST 2014


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.

—Dan


More information about the lambda-spec-experts mailing list