From stephan.herrmann at berlin.de  Thu Feb 14 18:37:31 2019
From: stephan.herrmann at berlin.de (Stephan Herrmann)
Date: Thu, 14 Feb 2019 19:37:31 +0100
Subject: enhanced for could be better integrated with type inference
In-Reply-To: <1028318868.292973.1548712462867.JavaMail.zimbra@u-pem.fr>
References: <2c52a58c-f066-b374-47b8-60a6e71fce84@berlin.de>
 <3EB98006-EB40-4D61-81A5-961369046A52@oracle.com>
 <1028318868.292973.1548712462867.JavaMail.zimbra@u-pem.fr>
Message-ID: <65ecf2d1-4015-066d-6047-09909687b860@berlin.de>

Hi R?mi,

thanks for explanations. If that's intended: fine.

Still, s.o. with write access to Jira may want to add this to
   https://bugs.openjdk.java.net/browse/JDK-8030361
   https://bugs.openjdk.java.net/browse/JDK-8179483

Obviously, resolving those issues might avoid more questions of the same kind :)

Stephan

On 28.01.19 22:54, Remi Forax wrote:
> 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 <stephan.herrmann at berlin.de
>         <mailto: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
>         <mailto: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
> 
> 
>