It leads to centralize_sumabs2!, which looks a lot like a re-implementation of reduce. I guess it’s not literally reduce as it has to index the array of pre-computed means at the same time as the input & output arrays. Are you suggesting a tidier way to implement that?
The case without dims is literally mapreduce(centralizedabs2fun(m), +, A) (just above). And this is what’s called by any map over slices, of course. It pre-computes the mean, whereas OnlineStats.jl does it in one pass, but seems slower.
I’m not sure if we’re talking about a notation for slicing anymore, though, so much as how best to (a) implement various reduction-like things efficiently, and (b) how best to call them.
For (a) it seems clear that the implementation cannot always just work on slices. For (b), one objection to an API which pretends you are working with slices, while actually doing something different, is that this seems a little fragile. It’s a magic fast path a little like the reduce(vcat, xs) one – which has surprising ways to step off the fast path accidentally. With the “ugly design” of having a dims method if and only if there exists a faster-than-slices implementation, at least you know what you’re getting.
I assume that’s the implicit rule in Base/std.lib. But might be wrong; are there examples of things with dims methods which do just always call mapslices or something? (Is seems that median does call mapslices, but uses mutation to do a bit better than mapslices(median, x; dims).)
Quite a few do share the same implementation as sum. Maybe it would help to list others you include in “etc”?