`TryIndex` and `TryIndexMut`

#[derive(Debug, Clone, PartialEq, Eq)]
pub struct NotFound<Idx> {
    pub index: Idx
}

pub trait TryIndex<Idx> {
    type Output;

    fn try_index(&self, index: Idx) -> Result<&Self::Output, NotFound<Idx>>;
}

pub trait TryIndexMut<Idx> {
    fn try_index_mut(&mut self, index: Idx) -> Result<&mut Self::Output, NotFound<Idx>>;
}

Do others support something like this?

The benefit of it being in the standard library is that we can use a subscript notation. Another benefit, over get and get_mut specifically, is that it's a trait, so we can pass around T: TryIndex members and implement it for multiple types of indices.

a[b] is already taken by Index, so we would have to use an alternate syntax like a?[b]. Alternatively we can just ditch subscript and rename try_index and try_index_mut to get and get_mut. It still may be a good idea to add to the standard library, because crates will derive TryIndex instead of providing their own get and get_mut which is not in a trait.

The main drawback of course is standard library bloat. There is try_traits which has TryIndex, but it only has around 9,000 downloads.

Another issue is redundancy and slight API differences, as get usually returns an Option, but here we return a Result which gives back the index. Some other crates do this as well, with their own NotFound error. Result is more "idiomatic" since mis-indexing is often an error, and useful for cases where Idx is not something you can copy. Though Idx being any more than a reference or number is very uncommon

Review the proposed TryIndex and TryIndexMut signatures and compare them with the linked try_traits crate. Resolve the competing choices around Result versus Option, trait naming, and indexing syntax; done means an RFC with a settled API and rationale.