BTW, why don't we guarantee that init is only used for empty collections?

how about removing "neutral"?

@nalimilan I believe we should keep these caveats. It is highly beneficial that reduce implementation can use init that is guaranteed to be the neutral element if we want to parallelize reduce. Or for having some parallelized API that is Base-compatible.

Consider reduce(op, xs; init = x0) with collect(xs) = [a, b, c, d]. If xs is a vector, we'd split xs in multiple threads equally:

x = reduce(op, [a, b]; init = x0)  # in thread 1
y = reduce(op, [c, d]; init = x0)  # in thread 2
ans = op(x, y)

However, it's not always possible to guarantee that split collections are non-empty. For example, xs might be:

xs = (x for x in [bad, bad, bad, bad, a, b, c, d] if x !== bad)

then the collection-splitting routine might produce

left = (x for x in [bad, bad, bad, bad] if x !== bad)
right = (x for x in [a, b, c, d] if x !== bad)

(That's how SplittablesBase.jl supports Iterators.filter)

Then, we'd have

x = reduce(op, []; init = x0)            # in thread 1
y = reduce(op, [a, b, c, d]; init = x0)  # in thread 2

@assert x == x0

ans = op(x, y)

As you can see, x0 is used even though xs itself is not empty and it is important that this is the neutral element so that we have ans == y.

Of course, the parallel implementation of reduce can completely ignore the init keyword and internally use appropriate neutral element. However, having a concrete init helps a lot for JIT'ing single-threaded basecase code. I think it'd be better to keep the current semantics documented in reduce.

OK, I was just curious whether we currently make use of that possibility. But for "neutral", IMHO the docstring should either mention that the behavior is unspecified (like for other docstrings), or the word should be removed.

I was just curious whether we currently make use of that possibility

It's possible but I'm not sure. I just think it's a reasonable API to keep it as-is.

@nalimilan @timholy Thanks a lot for your detailed review!