On Aug 13, 2017, at 6:27 AM, Tagir Valeev <amae...@gmail.com> wrote: > > Please review the preliminary implementation for Stream foldLeft and > foldRight operations: > > http://cr.openjdk.java.net/~tvaleev/webrev/8133680/r1/
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. 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. The foldRight operation is not a natural stream operation. It needs to operate in reverse sequential order, which a stream doesn't support. Better to make the buffering required for that reversal explicit to the user, IMO. I know it's a case of brief notation vs. "picky" explicitness; in this case the pickiness wins because there is an extra O(N) copy hiding in the pretty brevity. To me I think foldRight belongs (and also foldLeft) in Arrays and Collections, alongside sort. One reason we are being slow to add that sort of thing is because we plan to change our genericity story. Finally, although I can't quarrel too much with Scala's choice of terms, I find it hard to tell which is which. (I'm also left-handed.) Personally find foldLeft (and foldl) hard to remember, and would prefer something that makes it clear that you are processing elements from left to right. So foldFromLeft would help me. But in that case it should just be reduceFromLeft, since we already have reduce (which means place the brackets wherever). — John
