2.0: Don't iterate `Matrix`

[jariji]

Almost always when I iterate a matrix it's a typo for eachrow(m) or eachcol(m). If I want to do it on purpose, I'd prefer to use a non-allocating iterator denoted vec(m) or eachval(m).

[mikmoore]

Wouldn't this be really annoying for writing generic functions? The boilerplate seems awful. For example, a function like

function mysum(x)
	s = zero(eltype(x))
	for xx in x
		s += xx
	end
	return s
end

would need the extra methods

mysum(x::AbstractArray) = mysum(vec(x))
mysum(x::AbstractVector) = invoke(mysum, Tuple{Any}, x)

just to be sure that an AbstractArray was not iterated unless it was an AbstractVector. I imagine we'd end up needing this boilerplate on a lot of functions just to "undo" such a change. I'm also not convinced vec is zero-cost. Linear indexing into an IndexCartesian() style array requires divrem calculations to compute the Cartesian index.

Without some really compelling arguments, I think we're better off leaving it to the user to remember to eachcol when they want it.

[KristofferC]

What's 2.0?

[jariji]

I'm also not convinced vec is zero-cost.

Explicitly creating an iterator shouldn't require any more cost than doing it implicitly. If vec doesn't currently do that then it can be changed or eachval can be introduced.

Wouldn't this be really annoying for writing generic functions?

sum(m::AbstractArray) = reduce(+, eachval(m))

[mbauman]

This would need a larger philosophy of "what's an array" around it for motivation, I'd think. Currently, our arrays are collections of their items, and that's the rationale that underpins many of their behaviors (including this as well as other things like linear indexing and JuliaLang/LinearAlgebra.jl#42).

In any case, "what's 2.0?" is the best question here. :)

[mikmoore]

I assume "2.0" refers to this as a proposal for Julia v2.0 since this is obviously breaking.

I could see this making sense if we divorced the linear-algebraic concepts of "vectors, matrices, and tensors" from "n-dimensional arrays." Linear algebraic objects would likely just be trivial wrappers over n-dimensional arrays, but their behavior would diverge. For example, linear indexing into a 2-dimensional array can maybe make sense but linear indexing into (or iterating) a "matrix" does not. The multiplication of two matrices is defined but two arrays should either implement the element-wise product or no product at all (although still permitting .*, in either case). I would be very open to such a distinction. But as long we define the iteration of a "vector" to iterate its elements, we should do the same for "matrices" and "tensors."

[Jollywatt]

One of the many uses of linear iteration for Arrays is having

B = [f(x) for x in A]

result in an array the same shape as A. I think not having Arrays be linearly iterable would be spectacularly bad.

[timholy]

I really don't think this is a good idea; for one, it would break 99% of the code in JuliaImages. Should this really be on the 2.0 milestone? Or even remain open?