exception constraints for explicitly-typed lambdas

[Dan Smith]

Yes, looks like there's something wrong.  I'll explore further; I've created a bug:
https://bugs.openjdk.java.net/browse/JDK-8030478

On Dec 8, 2013, at 8:14 AM, Stephan Herrmann <stephan.herrmann at berlin.de> wrote:

> I may have a bug here, but from all I can see there's s.t.
> inconsistent as demonstrated by the following example:
> 
> class A {}
> class B extends A { void bar() {} }
> public class X {
>  public static void main(String[] argv) {
>    someWithIndex(getList(), (B b) -> b.bar()); // HERE
>  }
>  interface ItemWithIndexVisitor<E> {
>    public void visit(E item);
>  }
>  public static <G> void someWithIndex(List<G> list, ItemWithIndexVisitor<G> visitor) {}
>  static <I extends A> List<I> getList() { return null; }
> }
> 
> javac accepts this program, but I don't see how:
> 
> During invocation type inference for the marked call I get the following:
> 
> The set C contains:
>  constraint1: ⟨getList() ⊆throws java.util.List<G#0>⟩
>  constraint2: ⟨(B b) -> b.bar() ⊆throws X.ItemWithIndexVisitor<G#0>⟩
> 
> Input variables:
>  constraint1: none
>  constraint2: none
> 
> Output variables:
>  constraint1: G#0
>  constraint2: G#0
> 
> No input-output dependencies, so both constraints are picked.
> 
> The union of input variables is empty, nothing gets resolved nor substituted
> => constraints remain as given above.
> 
> During reduction of constraint2 we fail because of the unsubstituted
> inference variable G#0.
> This happens at 18.2.5 bullet 3:
>  one "of the function type's parameter types is not a proper type" -> FALSE
> 
> 
> I must admit that I don't have a good intuition for the terms "input"
> and "output variables", so I only have a "mechanical" guess as to where
> the conflict lies; the following don't harmonize:
> 
> [a] excluding parameters of explicitly-typed lambdas from input variables
> ("... the input variables include i) if the lambda expression is implicitly-typed...")
> 
> [b] checking parameters of all lambdas in 18.2.5
> 
> My guess is that [b] is wrong in some way (completely bogus or should add
> condition "if lambda expression is implicitly-typed" as done in 18.2.1.1).
> 
> Which is it?
> 
> best,
> Stephan