We are modifying through read-only/shared array views and this isinvalid, unless we have interior mutability (i.e using Cell, Mutex or similar).

And we'd like to avoiditer().zip() for ndarray, because it is much slower than it needs to be, we have Zip.

I'm working on makingArrayView<Cell<T>, D> a reality, a conversion we can use sometimes, - it allows us to have.. more fun like this. :)

We are modifying through read-only/shared array views and this is invalid, unless we have interior mutability (i.e using Cell, Mutex or similar).

On the other hand the method is taking a mutable reference toself, hence we are guaranteed to be the only ones operating on the array - we are opting out of the compiler safety guarantees because we know that two slices are not overlapping and that we have a unique handle on the data, hence the references are valid and to the outside world the operation should be safe.
Or am I interpreting this incorrectly?

Modifying through an ArrayView (without the Cell exception) is invalid full stop, because we treat it as we would treat a&[T] or&T. (We could go into details and exceptions at another time, maybe there's some argument for a more lenient view?)

x is a&T but we are modifying through it. That's not permitted.

Exceptions would come in to place if you somehow got a raw pointer out of an array view,maybe you'd then be able to make an argument. But since we go through explicit shared references here, we are at invalid full stop.

Given theS: DataMut trait bound on the method, aren't we dealing with anArrayViewMut, which is equivalent to a&mut [T]?
Just trying totruly understand, I am not trying to argue 😅

Sure, no problem. The types matter and there are shared refs used on the path to the swap. If we read the rust reference document this is UB, we can't just cast from &T and mutate.

Shuffle the array's xyz alongaxis.

We need a name for it, not sure if it should be slices. For the.lanes(axis) method we call them lanes - but those are perpendicular toaxis in that case.

I'd be tempted to call themplanes. We shuffle among the items in an AxisIter, right? Each such item isn - 1 dimensional in an ndarray.

That said it's good to have 2D explanations - how to shuffle rows and columns.

An alternative name could beprojections, which has the plus of not carrying an intuitive dimensionality along with it (I think 2D when I read planes).