Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

- Mail original - > De: "Peter Levart" > À: "Remi Forax" , "Brian Goetz" > Cc: "core-libs-dev" > Envoyé: Jeudi 21 Mars 2019 15:54:21 > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams > On 3/21

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On 3/21/19 2:17 PM, fo...@univ-mlv.fr wrote: for some reason i was convinced that IntStream.iterator() was returning a PrimitiveIterator.OfInt and not an Iterator, so yes, it will work but i don't understand why it's not BaseStream instead of Stream that inherits from Iterable. I think

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

- Mail original - > De: "Brian Goetz" > À: "Remi Forax" , "Stuart Marks" > Cc: "core-libs-dev" > Envoyé: Mardi 19 Mars 2019 00:58:04 > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams >> My

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

My fear is more than we will want in the future to have one code for all kinds of Stream, but Stream will have to implement Iterable while Stream will not, this not something you can actually do with the current generics, we may be able to do that with the reified generics but some

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

- Mail original - > De: "Stuart Marks" > À: "Remi Forax" > Cc: "core-libs-dev" > Envoyé: Samedi 16 Mars 2019 02:04:05 > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams >> I'm talking about the perf diffe

Re: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On 3/15/19 10:07 AM, Ivan Gerasimov wrote: On 3/15/19 1:51 AM, Peter Levart wrote: On 3/15/19 9:38 AM, Ivan Gerasimov wrote: Hi Peter! On 3/15/19 1:24 AM, Peter Levart wrote: On 3/15/19 9:03 AM, fo...@univ-mlv.fr wrote:   * @since 13   */ interface Once {} What do

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

I'm talking about the perf difference between stream.forEach and for(var element: stream), forEachRemaining may be slower because for the VM the ideal case is to see the creation of the Stream and the call to the terminal operation inside the same inlining horizon so the creation of the

Re: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On 3/15/19 1:51 AM, Peter Levart wrote: On 3/15/19 9:38 AM, Ivan Gerasimov wrote: Hi Peter! On 3/15/19 1:24 AM, Peter Levart wrote: On 3/15/19 9:03 AM, fo...@univ-mlv.fr wrote: * @since 13 */ interface Once {} What do you think of that? It's not clear to me if an

Re: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On 3/15/19 9:38 AM, Ivan Gerasimov wrote: Hi Peter! On 3/15/19 1:24 AM, Peter Levart wrote: On 3/15/19 9:03 AM, fo...@univ-mlv.fr wrote:   * @since 13   */ interface Once {} What do you think of that? It's not clear to me if an annotation, available at runtime, is not a

Re: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Hi Peter! On 3/15/19 1:24 AM, Peter Levart wrote: On 3/15/19 9:03 AM, fo...@univ-mlv.fr wrote: * @since 13 */ interface Once {} What do you think of that? It's not clear to me if an annotation, available at runtime, is not a better fit. Anyway, i'm not sure not sure

Re: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On 3/15/19 9:24 AM, Peter Levart wrote: On 3/15/19 9:03 AM, fo...@univ-mlv.fr wrote: * @since 13 */     interface Once {} What do you think of that? It's not clear to me if an annotation, available at runtime, is not a better fit. Anyway, i'm not sure not sure introducing

Re: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On 3/15/19 9:03 AM, fo...@univ-mlv.fr wrote: * @since 13 */     interface Once {} What do you think of that? It's not clear to me if an annotation, available at runtime, is not a better fit. Anyway, i'm not sure not sure introducing such interface/annotation worth its

Re: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

- Mail original - > De: "Peter Levart" > À: "Remi Forax" > Cc: "Brian Goetz" , "Stuart Marks" > , "core-libs-dev" > > Envoyé: Vendredi 15 Mars 2019 08:57:10 > Objet: Re: I don't understand why we need IterableO

Re: I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Hi, On 3/14/19 9:51 PM, Remi Forax wrote: yes, i think i prefer this solution, one Iterable to rule them all. First, it's not in the spirit of the Collection API to multiply the interfaces, by example, we have only one kind of Iterator and not an Iterator and a ReadOnlyIterator even if a lot

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On 3/15/19 12:16 AM, Stephen Colebourne wrote: On Thu, 14 Mar 2019 at 19:45, Brian Goetz wrote: Why not make `Iterator` implement `IterableOnce`? The default method would obviously just return `this`. Such a default would not conform to the contract, as IO requires that subsequent calls

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On Thu, 14 Mar 2019 at 19:45, Brian Goetz wrote: > Why not make `Iterator` implement `IterableOnce`? The default method > would obviously just return `this`. > > Such a default would not conform to the contract, as IO requires that > subsequent calls throw. IterableOnce.wrap(iterator) ? Not

I don't understand why we need IterableOnce ? Was: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

- Mail original - > De: "Peter Levart" > À: "Brian Goetz" , "Stuart Marks" > , "core-libs-dev" > > Envoyé: Mardi 12 Mars 2019 18:34:58 > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams > O

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

2019 at 7:37 PM Remi Forax wrote: >> >> Hi Tagir, >> try to do it now and you will see that you can't, because you can not write >> Iterable yet. >> Once we will get generics over value types, it will be a no-brainer. >> >> Rémi >> >> - Mail original

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

> A new concern from me is that this change would allow Iterable and > Stream to be used in foreach, but not Iterator. This seems like an > odd/sharp conceptual edge. Not actually a new concern — this was discussed back in JSR 335 as well. > Why not make `Iterator` implement `IterableOnce`?

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Now that Brian put it so nicely, I'm convinced and I'd like to draw back and support this proposal as is... On 3/14/19 3:50 PM, Stephen Colebourne wrote: On Thu, 14 Mar 2019 at 14:21, Brian Goetz wrote: There's a reason it took as long as it did for Stuart to come up with this proposal; all

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On Thu, 14 Mar 2019 at 14:21, Brian Goetz wrote: > There's a reason it took as long as it did for Stuart to come up with > this proposal; all the options were known for years, they all have > problems, and the net benefit is still relatively narrow, which means we > don't have a lot of budget

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

It think this alternative is not given fair comparison. 1st this is an instance method, so the foreach loop should read: for (T t : stream.asIterable()) {     ... } Let's keep sight of the goal here, which is: people find it a gap that Stream does not play cleanly with foreach.  And the

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Hi Stuart, The Alternatives section of the proposal is very thorough and it mentions the following alternative: "     An alternative adapter is to add a default method to Stream:     default Iterable asIterable() { return this::iterator; }     for (T t : asIterable(stream)) {         ...    

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

- Mail original - > De: "Stuart Marks" > À: "Remi Forax" > Cc: "core-libs-dev" > Envoyé: Mardi 12 Mars 2019 22:45:12 > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams > Hi Remi, > >> Stream.itera

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Hi Stuart! On 3/13/19 5:45 PM, Stuart Marks wrote: On 3/12/19 4:32 PM, Ivan Gerasimov wrote: If there were two new subtypes of Iterable introduced: IterableOnce and IterableMultipleTimes, then all existing Iterables could be retrofitted to implement one of these. It wouldn't

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On 3/5/19 12:43 PM, Mike Duigou wrote: I don't believe that I would use the proposed enhancement to the for statement. For me there is cognitive load reduction in using a symmetrical method for all iterations even if they end up being a little more complicated for individual cases. Usually,

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On 3/12/19 4:32 PM, Ivan Gerasimov wrote: If there were two new subtypes of Iterable introduced:  IterableOnce and IterableMultipleTimes, then all existing Iterables could be retrofitted to implement one of these. It wouldn't *automatically* solve the problem of 3rd party API, which

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Hello! Just an observation. If there were two new subtypes of Iterable introduced: IterableOnce and IterableMultipleTimes, then all existing Iterables could be retrofitted to implement one of these. It wouldn't *automatically* solve the problem of 3rd party API, which accepts an Iterable

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Due to how Iterable is specified now it does not promise multiple iterations, but due to how most (all that I know of except DirectoryStream or some 3rd party) Iterables are implemented now, the common expectation is that it does. By implementing more Iterable(s) that don't support multiple

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Hi Stephen, My slight concern is that the terminal operation is hidden and not immediately visible, which could be surprising. I do note that streams throw a clear exception if a terminal operation is called a second time which mitigates this to some degree. Yes, this is certainly a

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Hi Remi, Stream.iterator() can be really really slow, it uses a pull semantics while the whole Stream push values. When designing it, the lambda EG saw it as an "escape hatch" in order to interropt with a legacy code than require an Iterator and not more. If Stream.iterator() is slow, then

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Due to how Iterable is specified now it does not promise multiple iterations, but due to how most (all that I know of except DirectoryStream or some 3rd party) Iterables are implemented now, the common expectation is that it does. By implementing more Iterable(s) that don't support

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On 3/12/19 5:04 PM, Brian Goetz wrote: No. You have the LSP backwards (though this is easy to do.) IterableOnce means "*must throw* on subsequent use"; under this spec, an arbitrary Iterable is most certainly *not* an IterableOnce, and therefore an LSP violation. It sounds like you are

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

No.  You have the LSP backwards (though this is easy to do.) IterableOnce means "*must throw* on subsequent use"; under this spec, an arbitrary Iterable is most certainly *not* an IterableOnce, and therefore an LSP violation. It sounds like you are suggesting that we instead spec

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

- Mail original - > De: "Peter Levart" > À: "John Rose" , "Tagir Valeev" > Cc: "core-libs-dev" > Envoyé: Mardi 12 Mars 2019 11:29:22 > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams > Hi John, &g

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Hi John, On 3/12/19 12:07 AM, John Rose wrote: public static void main(String[] args) { for(int i : range(0, 100)) { System.out.println(i); } } It correctly compiles and prints numbers from 0 to 99. As IntStream extends BaseStream and BaseStream> defines Iterator iterator(), it would

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Also, if the upper bound is an expression, the range() approach makes it clear that the upper bound expression is intended to be evaluated once. > On Mar 11, 2019, at 4:07 PM, John Rose > wrote: > > P.S. I also saw the fiery objections to the range() idiom, and I

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

ed, Mar 6, 2019 at 7:37 PM Remi Forax wrote: >> >> Hi Tagir, >> try to do it now and you will see that you can't, because you can not write >> Iterable yet. >> Once we will get generics over value types, it will be a no-brainer. >> >> Rémi >> >>

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On 7/03/2019 12:48 am, Scott Palmer wrote: I don’t mean any offence, but I have to say, I strongly disagree with nearly everything you’ve written below. To me, the idea of making a stream of integers for a simple loop counter is hackish, confusing, verbose, and basically abusing the stream

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

"Tagir Valeev" > > À: "Stuart Marks" > > Cc: "core-libs-dev" > > Envoyé: Mercredi 6 Mars 2019 11:10:41 > > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams > > > Hello! > > > > By the way one

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On 3/7/19 9:41 AM, Peter Levart wrote: There is a benefit in the runtime though. The code can decide what to do with the passed-in Iterable depending on it implementing IterableOnce or not. Much like what RandomAccess interface does to List(s). The code can decide to dump the iterable into

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Hi, I see this is already discussed in the "Alternatives" section of the proposal (sorry for not reading this through before asking)... But I don't quite understand the following part that talks about making IterableOnce a supertype of Iterable: "However, doing so would require weakening

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Hi Stuart, According to Liskov substitution principle:     Subtype Requirement: Let ϕ ( x ) be a property provable about objects x of type T. Then ϕ ( y ) should be true for objects y of type S where S is a subtype of T. Let ϕ ( x ) for objects x of type Iterable be: "x.iterator() may be

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

I don’t mean any offence, but I have to say, I strongly disagree with nearly everything you’ve written below. To me, the idea of making a stream of integers for a simple loop counter is hackish, confusing, verbose, and basically abusing the stream concept. The only part I agree with is that it

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

bs-dev" > Envoyé: Mercredi 6 Mars 2019 11:10:41 > Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams > Hello! > > By the way one of the painful code patterns in modern Java is `for(int > i = 0; i newbies and prone to errors as the vari

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Hello! By the way one of the painful code patterns in modern Java is `for(int i = 0; i wrote: > > Hi all, > > Please review and comment on this proposal to allow Stream instances to be > used > in enhanced-for ("for-each") loops. > > Abstract > > Occasionally it's useful to iterate a Stream

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

I don't believe that I would use the proposed enhancement to the for statement. For me there is cognitive load reduction in using a symmetrical method for all iterations even if they end up being a little more complicated for individual cases. Usually, for me, I use streams. Even the more

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

On Fri, 1 Mar 2019 at 02:46, Stuart Marks wrote: > Please review and comment on this proposal to allow Stream instances to be > used > in enhanced-for ("for-each") loops. This all seems reasonable enough though of course not ideal. My slight concern is that the terminal operation is hidden and

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

: Vendredi 1 Mars 2019 03:43:44 > Objet: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams > Hi all, > > Please review and comment on this proposal to allow Stream instances to be > used > in enhanced-for ("for-each") loops. > > Abstract &g

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

The proposal looks good to me. In particular it's very nice to have this properly (ability to iterate only once) to be encoded in the type system. This could be helpful for static analysis tools to warn when IterableOnce is reused. Thanks! It would be good to see what you can come up with

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

One more alternative which could be considered (though it requires a language change) is to allow the inference of Iterable type for enhanced for when iteration value is a function expression and iteration parameter type is explicitly specified as T. In this case for(T t : stream::iterator) {}

Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Hello! The proposal looks good to me. In particular it's very nice to have this properly (ability to iterate only once) to be encoded in the type system. This could be helpful for static analysis tools to warn when IterableOnce is reused. Scanner case looks funny. In general such pattern could

Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams

Hi all, Please review and comment on this proposal to allow Stream instances to be used in enhanced-for ("for-each") loops. Abstract Occasionally it's useful to iterate a Stream using a conventional loop. However, the Stream interface doesn't implement Iterable, and therefore streams cannot