<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div><br></div><div>In case of a capture, the inference does not try to replace the capture by its bound. It's a limitation of the inference which tend to choose the most speciifc type where here, it has to use a less specific type.</div><div><br></div></div></blockquote><div><br></div><div><div>I don't quite understand the step by step "reasoning"  of the type inferer here, because naively this is what I would do if I was employed as a full time type inferer :). (I'm copying here my code again with some variable renaming for easier reference) Suppose I'm a compiler, and I see this:</div><div><br></div><div>```</div><div><T1> void arrayMethod(List<? super T1>[] args) {<br>    listMethod(Arrays.asList(args));<br>}<br><T2> void listMethod(List<List<? super T2>> list) { }<br></div><div>```</div><div><br></div><div>1. I look at `arrayMethod` and see 2 type variables to infer. One for `listMethod` (let's call it #L), and one for `Arrays.asList` (let's call it #A).</div><div>2. The first thing I see is that `Arrays.asList` returns `List<#A>`, and it is assigned to `List<List<? super #L>>`. This is easy to satisfy with #A = List<? super #L> (and this is actually the only possibility).</div><div>3. Then I go the next part, and see that args is of course `List<? super T1>[]` which must be assigned to `#A[]`, which is again easy to satisfy with #A = List<? super T1> (which is the only possibility again).</div><div>4. So, now I have to satisfy all equalities `#A = List<? super #L>` and `#A = List<? super T1>`, which implies that `List<? super #L> = List<? super T1>`, which is easy to satisfy by the choice #L = T1 (again, this is the only choice).</div><div>5. So, now I have resolved both variables:` #L = T1`, and `#A = List<? super T1>`, and indeed I can validate that this choice will satisfy every constraint.</div><div><br></div><div>I'm just puzzled here, because sometimes the type inferer can solve much more difficult problems, and this seems trivial compared to those.</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div></div><div>My bad, I should have written List<? super List<? super T>>.<br></div><div><br></div></div></blockquote><div><br></div><div>Surprisingly (to me), that would compile without explicitly specifying the type arguments (though of course that is not a type declaration that is acceptable for me). What surprises me here is that I would think that this would make the job of the type inferer harder, since now it is more difficult to find the correct types, since there are more options. Without the outer "? super" the inferer would be forced to make the correct type assignment (since there is always only one possibility). That is, when you write `List<? super List<? super T>`, now you get another fresh type variable to satisfy. Namely, you have to pick a type of `? super List<? super T>`. While in the other case your only option for this was `List<? super T>` (which is the only correct choice even in the `? super` variant.</div></div></div>