Implement Index and IndexMut for arrays

[pubfnbar]

Adds implementations of Index and IndexMut for arrays that simply forward to the slice indexing implementation in order to fix the following problem:

If you implement Index<MyIndexType> for an array, you lose all the other indexing functionality that used to be available to the array via its implicit coercion to a slice. An example of what I'm talking about:

use std::ops::Index;

pub enum MyIndexType {
    _0, _1, _2, _3, _4, _5, _6, _7,
}

impl<T> Index<MyIndexType> for [T; 8] {
    type Output = T;

    fn index(&self, index: MyIndexType) -> &T {
        unsafe { self.get_unchecked(index as usize) }
    }
}

fn main() {
    let array = [11u8; 8];

    println!("{:?}", array[MyIndexType::_0]); // OK
    
    println!("{:?}", array[0usize]); // error[E0277]
    //               ^^^^^^^^^^^^^ `[u8; 8]` cannot be indexed by `usize`
}

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @hanna-kruppe (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[pubfnbar]

Just to speculate a bit... If it becomes possible to use generic parameters in evaluating constant expressions, and if a BoundedUsize type (that wraps a bounded usize value) is added to the standard library and we want to be able to use it to index (large enough) arrays without bounds checking, it might look something like this:

pub struct Predicate<const P: bool>;

pub trait Satisfied {}

impl Satisfied for Predicate<true> {}

// Guarantees that if `x` is a `BoundedUsize<A, B>` value, then `x.0 >= A && x.0 <= B && A <= B`
pub struct BoundedUsize<const A: usize, const B: usize>(usize)
where Predicate<{ A <= B }>: Satisfied;

impl<T, const N: usize, const A: usize, const B: usize> Index<BoundedUsize<A, B>> for [T; N]
where Predicate<{ A <= B && B < N }>: Satisfied
{
    type Output = T;

    fn index(&self, index: BoundedUsize<A, B>) -> &T {
        unsafe { self.get_unchecked(index.0) }
    }
}

[scottmcm]

Note that, when LLVM knows the index is in-bounds, it already removes the bounds check, even when indirected through a slice.
Demo: https://rust.godbolt.org/z/hWYG58

[pubfnbar]

It would be interesting to test whether this PR breaks any code in crates.io (but I don't know how to do that). I'm pretty sure that at least the following code would stop compiling:

use std::ops::Index;

enum Idx {
    _0,
    _1,
}

impl<T> Index<Idx> for [T] {
    type Output = T;

    fn index(&self, idx: Idx) -> &T {
        Index::index(self, idx as usize)
    }
}

// This PR would cause there to be a clashing std library implementation of `Index<Idx> for [T; 2]`
impl<T> Index<Idx> for [T; 2] {
    type Output = T;

    fn index(&self, idx: Idx) -> &T {
        unsafe { self.get_unchecked(idx as usize) }
    }
}

fn main() {
    let array = [11, 22];
    let slice: &[u8] = &array;
    
    println!("{:?}", array[Idx::_0]);
    println!("{:?}", slice[Idx::_0]);
}

I don't know if this means that this PR can be merged only in the next Rust Edition?

[Dylan-DPC-zz]

r? @KodrAus

[pubfnbar]

I'd like to clarify something. You might be wondering how it is even possible (for some non-std code) to implement an external trait (Index) for an external type (array) given that even The Book says that the orphan rule dictates that: "But we can’t implement external traits on external types". The answer is that this rule was relaxed by RFC #2451 - Re-Rebalancing Coherence, and you can read more about it here:

• Rust 1.41.0 accouncement
• The stabilization report
• The Rust RFC Book

[KodrAus]

Based on the precedent of #74060 I'd be comfortable stabilizing these signatures with their use of const generics, and since this has only been possible to write for ~6months I wouldn't expect a lot of breakage. But just in case anybody else thinks a crater run is necessary I'll kick one off that we can cancel if we don't think it's needed.

@rfcbot fcp merge

This proposes stabilizing implementations of Index for [T; N] that forward to [T].

[rfcbot]

Team member @KodrAus has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @KodrAus
• @dtolnay
• @sfackler
• @withoutboats

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[KodrAus]

@bors try

[bors]

⌛ Trying commit ef61d686043f1df450d5a580978b76af985da6d6 with merge 72f88fc4e9458f89516a0b8b0868f3718aec5b47...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 72f88fc4e9458f89516a0b8b0868f3718aec5b47 (72f88fc4e9458f89516a0b8b0868f3718aec5b47)

[KodrAus]

@craterbot check

[craterbot]

👌 Experiment pr-74989 created and queued.
🤖 Automatically detected try build 72f88fc4e9458f89516a0b8b0868f3718aec5b47
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[KodrAus]

It looks like we have a handful of regressions here for 2d indexes:

• conway-rs https://github.com/ryanavella/conway-rs
• EnigmaMachine https://github.com/ngc0202/EnigmaMachine
• kit https://github.com/weshardee/kit

Before we merge I'll follow up with these libraries (it looks like kit is the only one up on crates.io right now)

[pubfnbar]

Just wondering, why hasn't this been merged already?

[KodrAus]

Thanks for the ping @pubfnbar!

It looks like I didn't pay close enough attention to the breakage in the published crate here. It's actually unrelated.

I've left some edits to bump stabilization to 1.49.0. After that we should be good to merge.

[Mark-Simulacrum]

Please squash commits into one, too.

[pubfnbar]

Please squash commits into one, too.

@Mark-Simulacrum
If this was directed to me, then I must admit I don't know how to do that. After some googling I think it means I should download (or whatever the correct terminology is) this pull request (or maybe the whole Rust repository?) to my computer and use a command like git rebase <something>. I don't really know how to use git or GitHub - I created this pull request only by using this website (I've never done the git download thingy to my computer). But it seems that whoever is allowed to merge this can also "squash" the commits while he's at it (according to this).

[Mark-Simulacrum]

No worries, squashed for you (also bumped to 1.50, as that's the current nightly version).

@bors r=KodrAus rollup

https://rustc-dev-guide.rust-lang.org/git.html has some documentation on getting started with git, if you're interested, and feel free to drop by Zulip with any questions!

[bors]

📌 Commit c03dfa6 has been approved by KodrAus