Documentation for `ParallelIterator::fold` and/or `ParallelIterator::reduce` seam to be incorrect about rayon HOT 5 CLOSED

the operation passed to it has to be associative, which String::push_str definitely isn't

Isn't it? If you ignore the identity of the underlying storage, then a.push_str(&b) is just a concatenated with b. It only reuses a's memory to avoid an unnecessary allocation.

In particular, if a, b and c are String, then

a.push_str(&b);
a.push_str(&c);

stores the same value in a as

b.push_str(&c);
a.push_str(&b);

from rayon.

Or put differently, the operation is

fn concat(mut a: String, b: String) -> String {
  a.push_str(&b);
  a
}

which does fulfil

concat(a, concat(b, c)) == concat(concat(a, b), c)

from rayon.

Just realized my issue, I confused associative with commutative. My understanding was that if I had a list [a, b], turned it into a parallel iterator and called reduce on it, it was not determined if the reduction function f(x,y) was called as f(a, b) or f(b, a).

from rayon.

Probably should've clicked on the link in the reduce docs, however the fact that the example for reduce was commutative didn't help my confusion.

from rayon.

We do preserve the order of operands, with the exception of par_bridge().

from rayon.