Empty reductions return the identity

⌈/⍬ is the one I'd argue with. The most negative float is a real value, so a caller that forgets the empty case gets a plausible maximum and keeps going. Rust splits it the other way.

let empty: [i64; 0] = [];
let s: i64 = empty.iter().sum();
let p: i64 = empty.iter().product();
println!("{s} {p} {:?}", empty.iter().max());

That prints 0 1 None. Sum and product have identities and return them. i64::MIN would work as an identity for max, and Rust still returns an Option, so the caller has to say what empty means. Floats don't even get max on the iterator, since f64 isn't Ord. You write fold(f64::NEG_INFINITY, f64::max) and pick the APL answer by hand, which at least puts the choice at the call site.

It's the identity. ⌈/x,⌈/⍬ equals ⌈/x for any x. Concatenate, reduce, same answer. That is what lets a reduction compose over pieces. An Option breaks it. Every partial result needs unwrapping before the next step.

Forgetting the empty case is real. It comes from a caller who never thought empty could happen. There a None turns into an unwrap, which crashes instead of lying, and I grant that beats a quiet wrong maximum.

Go took a third road. slices.Max panics on an empty slice and its doc says so, which surprised me at first and now reads as honest, since the function has no answer to give.