RFC: deprecate cartesianmap

[JeffBezanson]

This function is redundant with CartesianRange, and is also a performance trap. We could eventually fix the performance, but I think there are enough other problems with this function. It's not really a map, but more like a cartesian_foreach, so it's misnamed plus its behavior is a bit odd. I think in the future we will want to use product iterators and/or CartesianRange instead.

It's a bit awkward that CartesianRange provides a CartesianIndex instead of a tuple. I'm not sure what to do about that, but it seems OK for now.

[stevengj]

cartesianmap is currently used in four packages: Blocks, DistributedArrays, ZipFile, and Zlib. Might be worth looking at what they are using it for and how replaceable it is in those contexts.

[JeffBezanson]

The commit contains a 1-line proof-by-@deprecate that it can be replaced :)

[timholy]

👍 from me.

Cartesian iteration was developed before #10380, which is why it doesn't use tuples. We can change that now, but I suspect it's better as 0.5 material.

[JeffBezanson]

Agreed. Actually there are 2 interesting issues there. First, tuples don't have the correct sort order: (2,1) should come before (1,2) in CartesianIndex space. Second, indexing an array with a tuple might be ambiguous. We'll have to decide whether all n-d indexing should be based on tuples.

[StefanKarpinski]

Life would be so much easier if mathematics weren't column-major.

[carnaval]

does this "mathematics" thing have an upstream bugtracker we can report to ?

[StefanKarpinski]

if only

[Jutho]

+1

[mbauman]

You'll want to change the returns in this function to continue since it's now a for loop.

[JeffBezanson]

Right you are, thanks.

[mbauman]

👍