Implement IntoIterator for [&[mut]] Box<[T; N], A>

[WaffleLapkin]

Revival of #124108

I copied the <[T; N] as IntoIterator>::Iter's impl, but this does not seem satisfying:

1. I had to make IndexRange public
2. this duplicates a lot of code
3. it's unclear if the copied unsafe and spec code is worth it

r? @scottmcm
maybe you have better implementation ideas.

[bors]

☔ The latest upstream changes (presumably #136572) made this pull request unmergeable. Please resolve the merge conflicts.

[WaffleLapkin]

@scottmcm anything I can do to move this forward?

[Mark-Simulacrum]

I guess this also needs rebasing + FCP, maybe starting with the FCP makes sense since it's not obvious to me this is worth it (especially if it needs an edition change...)

View changes since this review

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[WaffleLapkin]

@Mark-Simulacrum I don't think this requires edition handling or FCP, as per the FCP on the previous attempt at doing this:

• Add Box<[T; N]>: IntoIterator without any method dispatch hacks #124108 (comment)
• Add Box<[T; N]>: IntoIterator without any method dispatch hacks #124108 (comment)

@rustbot review

[WaffleLapkin]

I've also removed the complicated unsafe impl for now, making the BoxedArrayIntoIter a wrapper around vec::IntoIter. I'll add back the more complicated impl in a follow-up.

[Mark-Simulacrum]

I don't think this requires edition handling or FCP, as per the FCP on the previous attempt at doing this:

I think we do need FCP or at least libs-api meeting nomination to re-confirm that the >1 year old FCP from 2024 is still valid. Maybe a Crater run. This is a breaking change and there was some post-initial-FCP discussion on whether we should do the unsizing impl (#124108 (comment)). Making two breaking changes here feels unfortunate so we should decide upfront which we want, even if we think the change is otherwise reasonable.

I guess the current version of this PR proposes neither option and instead has a dedicated new iterator type (BoxedArrayIntoIter). I think that's entirely net-new surface area, right? It also means we're missing a chunk of impls (e.g., DoubleEndedIterator) that we'd get 'for free' with vec::IntoIter.

View changes since this review