Proposal: JDK-8148917 Enhanced-For Statement Should Allow Streams
forax at univ-mlv.fr
Sat Mar 2 21:19:48 UTC 2019
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.
This proposal has the side effect of making Stream more different from its primitive counterpart IntStream, LongStream and DoubleStream which may be problematic because we are trying to introduce reified generics as part of Valhalla (there is a recent mail of Brian about not adding methods to OptionalInt for the same reason).
And, the real issue is how to deal with checked exceptions inside the Stream API, i would prefer to fix that issue instead of trying to find a way to workaround it.
----- Mail original -----
> De: "Stuart Marks" <stuart.marks at oracle.com>
> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: 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.
> 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:
> Bug report:
> 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.
More information about the core-libs-dev