[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-lambda-spec-observers
Subject:    Re: enhanced for could be better integrated with type inference
From:       Remi Forax <forax () univ-mlv ! fr>
Date:       2019-01-28 21:54:22
Message-ID: 1028318868.292973.1548712462867.JavaMail.zimbra () u-pem ! fr
[Download RAW message or body]

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@oracle.com>
> À: lambda-spec-experts@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@berlin.de |
> > stephan.herrmann@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@openjdk.java.net |
> > lambda-spec-comments@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


[prev in list] [next in list] [prev in thread] [next in thread]