I think the whole thing is caused by the notion that there are, somehow, signed and unsigned numbers. It reality it's an illusion, figment of our imagination, in reality these don't exist. Not in hardware, anyway.
Today's computers don't distinguish between
4294967295u32. It's the exact same bit pattern and, importantly, all operations (
/) behave identically, too (CPUs don't have separate instructions which deal with signed or unsigned numbers).
The only thing which distinguishes them is overflow checking.
And that doesn't happen with values, it happens with operations on values.
But of course Rust can not expose that. The whole story of Rust is the same thing repeated bazillion times: take simple and beautiful (but unfamiliar for most people!) mathematics concept and turn into ugly (yet familiar to most people!) form.
When Rust deals with integers it takes a simple ℤ ₂ᴺ ring and turns it into a couple of types, one signed, one unsigned.
Given that fact I don't see how allowing to use signed integers as indexes would help anyone: by the time when you have and
i64 memory cell it's too late to check for overflow.
-42i32 can be an overflow or [incorrectly typed]
4294967254, you just never know at the point when it's used as index, you need to look on the place where is it calculated. If something like that is presented as array index it's programmer's error and programmers responsibility to fix the issue.
Current approach makes it very clear and usually leads to prominent crash which programmer would have to resolve anyway. I don't see how adding the ability to use
isize as index would help. It would just add more confusion IMO.