`ndarray::stack` changed behavior w.r.t layout between 0.15.1 and 0.15.2

[msalib]

Before 0.15.3, stack would return an array with C-layout when given C-layout views. But with 0.15.3, this behavior changed and now we get F-layout outputs. This demonstration program will succeed if you pin ndarray to "=0.15.2" and fail if you pin to "=0.15.3":

use ndarray::{arr2, stack, Axis};

fn main() {
    // Here are some 2x3 arrays.
    let a = arr2(&[[1, 2, 3], [4, 5, 6]]);
    let b = &a * 2;
    assert_eq!(a.shape(), b.shape());
    assert_eq!(a.shape(), [2, 3]);

    // When we stack them with Axis(2), we'll get a 2x3x4 array
    // with the last dimension stored continuously.
    let c = stack(Axis(2), &[a.view(), b.view(), a.view(), b.view()]).unwrap();
    assert_eq!(c.shape(), [2, 3, 4]);
    assert!(c.is_standard_layout());
    dbg!(&c);
}

I don't see anything about the layout of stack's return value in the docs so I assumed that it would match the inputs. So even if no code behavior change is warranted, the docs should really include a note explaining that you might get a different layout than your inputs.

[bluss]

When I try this, the test fails on both 0.15.2 and 0.15.3. It passes on 0.15.0 and 0.15.1. So it's changes between 0.15.1 and 0.15.2 we should look at. It must be because of the reimplementation of stack in 0.15.2 (#932). How we handle memory layout is subject to constant improvement, so it's hard to say what should be guaranteed here, stack doesn't guarantee any particular memory layout and tries to be efficient.

[msalib]

Ah, sorry for the confusion then!

And I totally appreciate stack taking advantage of different layouts for performance wins, but some comment in the documentation to that effect would be nice!