From brian.goetz at oracle.com  Mon Jan 28 20:08:59 2019
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 28 Jan 2019 15:08:59 -0500
Subject: Fwd: enhanced for could be better integrated with type inference
References: <2c52a58c-f066-b374-47b8-60a6e71fce84@berlin.de>
Message-ID: <3EB98006-EB40-4D61-81A5-961369046A52@oracle.com>

Received on the -comments list.



> Begin forwarded message:
> 
> From: Stephan Herrmann <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: 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20190128/606e74bc/attachment.html>

From forax at univ-mlv.fr  Mon Jan 28 21:54:22 2019
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 28 Jan 2019 22:54:22 +0100 (CET)
Subject: enhanced for could be better integrated with type inference
In-Reply-To: <3EB98006-EB40-4D61-81A5-961369046A52@oracle.com>
References: <2c52a58c-f066-b374-47b8-60a6e71fce84@berlin.de>
 <3EB98006-EB40-4D61-81A5-961369046A52@oracle.com>
Message-ID: <1028318868.292973.1548712462867.JavaMail.zimbra@u-pem.fr>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/lambda-spec-experts/attachments/20190128/ebf4e725/attachment.html>