Hello, John! > I think s.foldLeft(op) is the same as s.sequential().reduce(op). > If that's the case, there's no need for it, except in documentation.
This implementation could be worse for parallel stream. First, as Brian already mentioned, forEachOrdered (thus my proposed implementation) could still benefit from parallelization, e.g. if upstream contains expensive mapping operation. Second, upstream may contain full stop operation (e.g. sorted()). In this case everything before sorting including sorting itself would be parallelized nicely. When you use sequential(), you force all the stream to be sequential, killing the parallelism on all the stages. Also note that we are speaking about extending the interface, not the implementation. It's not specified how exactly reduce(op) must behave and third-party implementations in wild may reduce in another order, actually relying on op assotiativity. E.g. for stream of four elements the implementation is free to reduce like op(op(e1, e2), op(e3, e4)). As long as associativity holds, the result will be indistinguishable from op(op(op(e1, e2), e3), e4). Using forEachOrdered is much more reliable as its behavior is more constrained by documentation. Finally this does not solve the problem with more popular version of foldLeft which has seed element (possibly of another type). In this case you cannot delegate the call to existing reduce without providing a bogus combiner (and hoping that it's never called for sequential stream, even though it's not specified). > A quick, inexpert read of package-info.java suggests to me that > the encounter order of a sequential ordered stream is stable, > and therefore the result of executing a reduce on such a stream > should always produce the same order of operations. Which > order? Well of course, the one given in the javadoc. Which > is an implementation of your foldLeft, minus the unnecessary > buffering. My implementation has no unnecessary buffering. It just stores the accumulator inside the forEachOrdered consumer. Practically the same is made inside reduce implementation. The result of executing a reduce could be the same even if operation order is different, because spec requires that op must be associative, so een sequential reduce may rely on associativity. As for foldRight, some considerations about reverse() operation are mentioned in Stuart's comment in the issue: https://bugs.openjdk.java.net/browse/JDK-8133680?focusedCommentId=13861795&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13861795 Indeed creating reverse() operation would be nice, but it will require much more effort to support in existing spliterators. Also we should provide default implementation for Stream interface as well as more optimal specific implementation for JDK Stream. This is doable, but of course I cannot write it by myself without support from other OpenJDK developers (or at least without strong evidence that such feature could be accepted). With best regards, Tagir Valeev.
