Fortran has 1st class many-dimensional arrays; can you really do that efficiently (as in "works great with a loop nest optimizer/LNO" and "has pretty syntax" and "there's one way to do it") as a Rust extension? C++ says "NOOOOOOO!!!" I don't know Rust well enough to answer the question.

You can do `arr[(1,2,3)]` in Rust (not pretty, but ok). Assuming you've marked the indexers as inline, LLVM should be able to optimize it pretty well. If it doesn't, optimizations can be added.

Rust can't enforce "one way to do it" since this would be done as a library. Currently there's only one library offering this (ndarray), so in a sense there's only one way to do it :)

What does arr[(1,2,3)] have to do with what I asked for? The code that I write for my personal scientific stuff (numerical hydrodynamics) needs loop jamming/fusion and splitting, SIMD without having to use any special notation, and other stuff which is typically provided by compiler LNO. I happen to have interchanged loops in my code, but if I goofed that up, it'd be nice for the compiler to do it for me.

No array slices needed. Plain Fortran 77 notation provides what I need.

> What does arr[(1,2,3)] have to do with what I asked for

"has pretty syntax", was just showing what the syntax would look like in Rust.

LLVM autovectorizes, and does many loop optimizations. I suspect LNO exists, but if it doesn't there's nothing preventing it from being added afaict.

Was mostly explaining what the status of this in Rust is. It's not awesome, but not horrible either.

Thanks for trying to be helpful. The place where C and C++ goes wrong is multi-dimensional arrays. Some googling tells me that narray gives Rust syntax like foo[[1,2,3]] for a 3 dimensional array. I have no guess if this optimizes well or not.

It will compile down to `foo[1][2][3]` and get optimized the same way. Rust additionally does hint a lot more about aliasability to LLVM (everything is restrict by default, basically), so there probably is more scope for optimization here.

I'm not an expert in that domain, but to my mind, the two big things are

* lack of type-level integers

* lack of explicit SIMD on stable Rust