Better error message when accidentally use an array instead of tuple for into_shape?

Start by reading the into_shape() documentation and the “ndarray for numpy users” section mentioned in the issue. Clarify the array-versus-tuple shape distinction and the different shape representations; done means the relevant documentation explains this footgun clearly, unless maintainers choose an API-level improvement instead.

I just lost an hour to the following incorrect code:

    #[test]
    fn test_ndarray_eq()
    {
        let a = ndarray::arr3(&[[[true]]]);
        let a2 = a.into_shape([1,1]).unwrap();
        let a3 = a2.into_shape([1,1,1]).unwrap();
        assert!(a == a3,"Arrays are not equal!");
    }

error[E0308]: mismatched types
--> src/lib.rs:156:20
|
156 | assert!(a==a2, "Arrays do not match!");
| ^^ expected array of 3 elements, found struct ndarray::IxDynImpl
|
= note: expected type ndarray::ArrayBase<_, ndarray::Dim<[usize; 3]>>
found type ndarray::ArrayBase<ndarray::OwnedRepr<bool>, ndarray::Dim<ndarray::IxDynImpl>>

The source of the problem has nothing to do with "==", nothing to do with IxDynImpl, and isn't even on the line the error is thrown. If you print all of the arrays using println!, they all look like they have the correct shape, stride, and contained values.

This happened in my original code because I passed the output of .shape() into into_shape. It happened n the above minimized example because I passed the dimensions as arrays "[...]" instead of as tuples "(...)".

If there's anything that can be done to smooth out this sharp edge in the API, consider this a feature request. Failing that, maybe throw big warnings about this footgun in the into_shape() documentation (which says nothing about the type of the input since it's generic over E), and also in the section of the "ndarray for numpy users" section where you at least mention the ugly existence of three different representations of the shape of an array, with different methods to get them.

By the way, thanks for writing ndarray; I would not have even considered Rust without it.