Matt Bauman

> Do we want to specify whether it's `op(init, _)` or `op(_, init)`? I don't think there's a meaningful reason to do so, because subsequent steps might be `op(op(...), _)`...

I don't like requiring that `init` needs to be a left-argument to `op` because that means that `foldr` would not be a valid implementation for `reduce`. But otherwise I agree....

As an example, yes.

OK, I've pushed a new re-wording. I find this more clear, personally. We seem have a very solid consensus that "reduce-like functions use init one or more times" so I've...

I have two reasons why that's not a major concern in my view. One is that there are three "types" of arguments that get passed to `op`: * `init` itself...

Perhaps more succinctly, just look at `foldl`. With `init`, it will pass *all* its `itr` values as right-args. All the left args (except one) are results from previous operations. And...

Well the previous documentation explicitly says that it may or may not be used... but it'd probably be a good idea to get an idea of how many folks were...

I've become completely radicalized against initial value guesswork _when it's not specified_, and the proposed behavior change here is only about what to do when `init` _is specified_. Guessing at...

The usecase is https://github.com/staticfloat/Perftests.jl: https://github.com/staticfloat/Perftests.jl/blob/a8d48b6cf4efd86fb81ce0d956fb90d491cf7621/benchmarks/array/perf.jl#L29-L32. The `@perf` macro wraps `@benchmark`. There may be ways to support this by doing setup before the loop.

Working as intended (but needs to be documented). The latest swing of the pendulum has `@benchmark` working with the same semantics as the `@code_*` macros — it evaluates all arguments...