Successive transpositions

[clbarnes]

Serialising the transpose codec as "F" or "C" implies a global knowledge of the resulting memory order. What happens if two transpose codecs are given? By my reading of the spec, a C order array which goes through two "F" transpose codecs will come out the other end in the initial (C) order, which feels a bit wrong. It might also be confusing to users of languages which use F-order arrays to begin with to apply an F transpose in order to make a C-order array. Might it be more clear to serialise as either a permutation or just true to mean reverse all dimensions? There's not a lot of point serialising a null transpose.

[jbms]

I originally proposed those constants for the relationship with the zarr v2 order field, but I agree that it leads to confusing results when applied more than once. I would say that it would be best to just require a permutation and remove the "C" and "F" constants.

[clbarnes]

Not having F and C order in my head is definitely making it easier to think about transpositions, slicing etc.! There might still be some convenience in having a true or false variant for "transpose everything" and "no op" but creating those shortcuts could just be left up to the implementor.