yes,i should have been more specific, you can not *without* having some boxing
in the middle.
Rémi
----- Mail original -----
> De: "Tagir Valeev" <amae...@gmail.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "Stuart Marks" <stuart.ma...@oracle.com>, "core-libs-dev"
> <core-libs-dev@openjdk.java.net>
> Envoyé: Jeudi 7 Mars 2019 11:33:20
> Objet: Re: Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams
> Hello, Remi!
>
> It actually works thanks to auto-boxing/unboxing. E.g. this
> implementation works:
>
> static Iterable<Integer> range(int from, int to) {
> return () -> new PrimitiveIterator.OfInt() {
> int cur = from;
>
> @Override
> public int nextInt() {
> if (cur >= to) {
> throw new NoSuchElementException();
> }
> return cur++;
> }
>
> @Override
> public boolean hasNext() {
> return cur < to;
> }
> };
> }
>
> 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<Integer, IntStream> and BaseStream<T, S extends
> BaseStream<T, S>> defines Iterator<T> iterator(), it would be no
> problem with using IntStream.range in such code pattern were
> BaseStream extends IterableOnce<T>.
>
> Of course this produces unnecessary garbage, as I said.
>
> With best regards,
> Tagir Valeev.
>
> On Wed, Mar 6, 2019 at 7:37 PM Remi Forax <fo...@univ-mlv.fr> wrote:
>>
>> Hi Tagir,
>> try to do it now and you will see that you can't, because you can not write
>> Iterable<int> yet.
>> Once we will get generics over value types, it will be a no-brainer.
>>
>> Rémi
>>
>> ----- Mail original -----
>> > De: "Tagir Valeev" <amae...@gmail.com>
>> > À: "Stuart Marks" <stuart.ma...@oracle.com>
>> > Cc: "core-libs-dev" <core-libs-dev@openjdk.java.net>
>> > 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<bound; i++)` which is very verbose, hackish, confusing for
>> > newbies and prone to errors as the variable need to be repeated three
>> > times. Also the variable is not effectively final, despite it never
>> > changes within the loop body, so could have been considered as
>> > redeclared on every loop iteration (like in for-each). With the new
>> > proposal it's possible to write `for(int i : range(0, bound).boxed())`
>> > (assuming import static j.u.s.IntStream.range), which looks much
>> > better, though it has obvious performance drawback. Moving
>> > IterableOnce to BaseStream would enable to use `for(int i : range(0,
>> > bound))` which looks even better, though again we have plenty of
>> > garbage (but considerably less than in previous case!). I wonder
>> > whether Java could evolve to the point where such kind of code would
>> > be a recommended way to iterate over subsequent integer values without
>> > any performance handicap.
>> >
>> > With best regards,
>> > Tagir Valeev.
>> >
>> > On Fri, Mar 1, 2019 at 9:47 AM Stuart Marks <stuart.ma...@oracle.com>
>> > 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 using a conventional loop.
>> >> However,
>> >> the Stream interface doesn't implement Iterable, and therefore streams
>> >> cannot be
>> >> used with the enhanced-for statement. This is a proposal to remedy that
>> >> situation by introducing a new interface IterableOnce that is a subtype of
>> >> Iterable, and then retrofitting the Stream interface to implement it.
>> >> Other JDK
>> >> classes will also be retrofitted to implement IterableOnce.
>> >>
>> >> Full Proposal:
>> >>
>> >> http://cr.openjdk.java.net/~smarks/reviews/8148917/IterableOnce0.html
>> >>
>> >> Bug report:
>> >>
>> >> https://bugs.openjdk.java.net/browse/JDK-8148917
>> >>
>> >> Webrev:
>> >>
>> >> http://cr.openjdk.java.net/~smarks/reviews/8148917/webrev.0/
>> >>
>> >> Note, this changeset isn't ready to push yet. In particular, it has no
>> >> tests
>> >> yet. However, the implementation is so simple that I figured I should
>> >> include
>> >> it. Comments on the specification wording are also welcome.
>> >>
>> >> Thanks,
>> >>
> > > > s'marks
