Why doesn’t Rust have reverse indexing / indexing from end for arrays?

Since the size of array types in Rust are already known at compile-time, I was wondering what might be the reason for not having reverse indexing? By reverse indexing, I mean arr[-1] to access the last element of array arr

I can think of several reasons:

• If you calculate the index, you can easily calculate a negative index by mistake. This would not be a memory-safety issue in Rust, but bounds-checking would no longer work reliably. This would make a common class of bugs impossible to detect at run-time.
• It would have a run-time cost (it needs an addition, at least, compared to bounds-checking). It would be generating machine code that isn't needed in most cases, hurting performance.
• Arrays may have a known size at compile-time, reducing the cost, but slices do not. Surely you'd want indexing to mean the same for both slices and arrays.
• arr[-1] implies that the index is signed, so if you have a pointer you can use indexing only to access half of the possible memory range. This can be a problem in systems programming where the highest memory bit may have a special meaning.
• Also, in C++ mixing signed and unsigned integers has a long history of pain and bugs. I'm not sure if this reasoning applies here, but at least many would feel better to avoid mixing signed and unsigned types whenever possible. (E.g. it requires care to compare those types with correct overflow handling.)