enhanced for could be better integrated with type inference

[Stephan Herrmann]

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
> 
> 
>