RFR: JDK-8133680 add Stream.foldLeft() terminal operation

[Tagir Valeev]

Hello, Rémi!

People don't use forEachOrdered not because they don't care about
order, but because they don't care about parallelism and forEach does
the same (for sequential stream) with a shorter name. Similar to
foldLeft. Currently people often use reduce instead of missing
foldLeft, feeding reduce with non-associative operation, identity
element violating identity properties and specifying a bogus combiner,
because they just don't care about parallelism. Here are some
examples:

https://github.com/TheDIM47/RestSample/blob/1cc0c6f9f4c6a1980b608ddcbc743dcb3f17eeb9/src/main/java/com/juliasoft/rest/CalculatorService.java#L20
  .reduce(values[0], (x, y) -> x - y); -- associativity is clearly violated
https://github.com/mary-mogreen/java8_training/blob/8b0bb9e87905def30757b7d8aedbb950b936b24d/src/ch02/ex10/StreamUtils.java#L19
  .reduce(0.0, (x, y) -> {count.incrementAndGet();return x + y;}); --
op has side-effect and will definitely yield the wrong result in
parallel

Well it's hard to search through github as it's filled with student
projects. Nevertheless people sometimes recommend to use reduce when
no combiner is possible:
https://stackoverflow.com/a/43660838
Note that answer is upvoted and accepted, so you may expect that
similar code appears in the wild. Some libraries even provide a
"convenient" no-combiner which throws:
https://github.com/poetix/protonpack/blob/0ba7e9d4eb63de3e7d40755c562e9a64b05ea927/src/main/java/com/codepoetics/protonpack/collectors/CollectorUtils.java#L125

Also people often try to use non-associative op in reduce and wonder
why it works incorrectly in parallel:
https://stackoverflow.com/q/32799937
https://stackoverflow.com/q/33375335

You may only guess how many people use reduce incorrectly in real
projects. Were foldLeft alternative present, people would use it and
their code would be correct (though not so fast) even when .parallel()
is specified. Sometimes people ask questions where the answer would be
"Use foldLeft... ah, it doesn't exist":

https://stackoverflow.com/q/30736587

With best regards,
Tagir Valeev.

On Wed, Aug 16, 2017 at 7:56 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> Yes,
> reconsidering old decision is healthy, but you need provide some data/good
> reason
> to explain what has changed.
> By example, I'm curious about the number of occurrences of forEachOrdered in
> the wild, given that fold left (a kind of reduce) will be even less used
> than a forEachOrdered (a kind of forEach).
>
> Rémi
>
>
>
> On August 14, 2017 2:58:18 AM GMT+02:00, Tagir Valeev <amaembo at gmail.com>
> wrote:
>>
>> Hello, Remi!
>>
>> Yes, I know. But times change and old decisions could be reconsidered.
>> After all, forEachOrdered was included and its semantics is essentially the
>> same as in foldLeft with respect to parallel streams.
>>
>> With best regards,
>> Tagir Valeev.
>>
>> 14 авг. 2017 г. 2:45 AM пользователь "Remi Forax" <forax at univ-mlv.fr>
>> написал:
>>>
>>> Hi Tagir,
>>> foldLeft (and foldRight) were intentionally not included in the Stream
>>> API because as you know, their semantics is too strong to be useful for
>>> parallel streams.
>>>
>>> regards,
>>> Rémi
>>>
>>> ----- Mail original -----
>>> > De: "Tagir Valeev" <amaembo at gmail.com>
>>> > À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>> > Envoyé: Dimanche 13 Août 2017 15:27:36
>>> > Objet: RFR: JDK-8133680 add Stream.foldLeft() terminal operation
>>>
>>> > Please review the preliminary implementation for Stream foldLeft and
>>> > foldRight operations:
>>> >
>>> > http://cr.openjdk.java.net/~tvaleev/webrev/8133680/r1/
>>> >
>>> > This implementation has no tests yet. Before writing them I'd like to
>>> > be sure that this enhancement could be accepted in general (or
>>> > probably foldLeft is accepted and foldRight is not?) Could anybody
>>> > sponsor it when it will be complete?
>>> >
>>> > Thank you in advance!
>>> >
>>> > Tagir Valeev.
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.