enhanced for could be better integrated with type inference

[Remi Forax]

Hi Stephan, 
i'm notorious bad at trying to recollect details of discussions, anyway, i will try: 

your test case can be reduced to: 
for (String s : Collections.emptyList()) { 
... 
} 

as you said the target type can be Iterable<String> and String[], so there are two issues: 
- what is the algorithm in this case ? we try to infer both and if one compile it's ok ? what if both compiles, worst, Iterable<String> is a functional interface so back propagating Iterable<String> means String can use used to infer the return type of a lambda, it was ruled as a little too magical by the EG. 
- what if in the future we want to introduce a new kind of iteration which doesn't implement Iterable, like by example the Clojure's cursor (cursor are not mtuable yay!), we likely can not do that if we allow back-propagation, or will have to say, we need to first check with Iterable<String> and String[], and as a second citizen, try with Cursor<String> ? 

Furthermore, there is a simple solution, provide a type argument 
for (String s : Collections.<String>emptyList()) { 
... 
} 
so it was decided to not try to back-propagate Iterable<String> and String[]. 

Rémi 

> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: lambda-spec-experts at openjdk.java.net
> Envoyé: Lundi 28 Janvier 2019 21:08:59
> Objet: Fwd: enhanced for could be better integrated with type inference

> Received on the -comments list.

>> Begin forwarded message:

>> From: Stephan Herrmann < [ mailto:stephan.herrmann at berlin.de |
>> stephan.herrmann at berlin.de ] >
>> Subject: enhanced for could be better integrated with type inference
>> Date: January 26, 2019 at 4:39:44 PM EST
>> To: [ mailto:lambda-spec-comments at openjdk.java.net |
>> lambda-spec-comments at openjdk.java.net ]

>> Hi,

>> I know, JSR 335 has sailed time ago, but still I'd like to share a late find:

>> //---
>> import java.util.*;
>> public class X {
>> void testForeach1(boolean b, List<String> list) {
>> Iterable<String> it = b ? Collections.emptyList() : list;
>> for (String s : it) {
>> }
>> }
>> void testForeach2(boolean b, List<String> list) {
>> for (String s : b ? Collections.emptyList() : list) {
>> }
>> }
>> }
>> //---

>> Method testForeach1() compiles OK, but if you inline 'it' to yield
>> testForeach2() then type inference will fail, saying, e.g.:
>> incompatible types: Object cannot be converted to String

>> Did the EG back then have specific reasons, to view the collection expression as
>> a standalone expression? Apparently, if type inference could optionally use
>> String[] or Iterable<String> as the target type for the collection expression,
>> then more expressions could be admitted in this position, some of which would
>> likely make more sense than the above example :)

>> Just wondering,
>> Stephan