Regarding "indexing by signed integer", I'm pondering this situation:
fn get_i128<T>(slice: &[T], index: i128)->Option<&T> {
slice.get(index)
}
At the moment, this doesn't compile. The naive approach – which is an easy mistake to make – is this:
fn get_i128<T>(slice: &[T], index: i128)->Option<&T> {
slice.get(index as usize)
}
This behaves incorrectly, because the integer -2^64 is not a valid index into the slice, but get_i128(slice, -(1<<64)) would return Some (assuming the slice has nonzero length), because (-(1<<64)) as usize is 0usize. The correct implementation is
fn get_i128<T>(slice: &[T], index: i128)->Option<&T> {
index.try_into().and_then(|usize_index| slice.get(usize_index))
}
which is more verbose and less readable. In this case, it can be shortened to
fn get_i128<T>(slice: &[T], index: i128)->Option<&T> {
slice.get(index.try_into()?)
}
but normally the situation of indexing by a signed integer would arise in the middle of a longer function, where this improvement isn't available.
(EDIT: This next thing wasn't quite correct; see CAD97's reply below:) I don't have a specific proposal for how to improve this (I assume it would be a breaking change to make get() take a polymorphic argument, and adding a separate method would have issues with discoverability and bloat). I just wanted to make a note of the pitfall.
I guess this is similar to what newpavlov said more concisely earlier. But it's a bummer that adding more Index impls wouldn't be able to extend the same protections to get().