impl `AsRef<[T; N]>` and `AsMut<[T; N]>` for `[T; N]`

[GrigorenkoPV]

Problem statement

From the docs:

Ideally, AsMut would be reflexive, i.e. there would be an impl<T: ?Sized> AsMut<T> for T with as_mut simply returning its argument unchanged. Such a blanket implementation is currently not provided due to technical restrictions of Rust’s type system (it would be overlapping with another existing blanket implementation for &mut T where T: AsMut<U> which allows AsMut to auto-dereference, see “Generic Implementations” above).

A trivial implementation of AsMut<T> for T must be added explicitly for a particular type T where needed or desired. Note, however, that not all types from std contain such an implementation, and those cannot be added by external code due to orphan rules.

While it will probably be a long time until Rust is able to provide impl<T: ?Sized> AsMut<T> for T (if ever), I think it is absolutely feasible to at least provide some implementations for a few more std types. In particular, I believe that [T; N] was never covered simply because AsRef well predates const generics, which are required to provide such an impl, (1.0.0 vs 1.51.0, for reference).

There's no such a roadblock anymore, but over the years Rust ecosystem has became quite reliant on the fact that array.as_ref() currently behaves like array.as_slice() due to a Deref desugaring of effectively { let tmp: &[_] = array.deref(); tmp.as_ref() }. Luckily, there has already been some prior art in the form of providing an IntoIterator implementation for arrays, which would only be available via method call syntax on Edition 2021 and later: https://doc.rust-lang.org/edition-guide/rust-2021/IntoIterator-for-arrays.html

I consider the usage of .as_ref() in places of .as_slice() to be non-idiomatic and inferior, at the very least because as_slice() has been const-stable since 1.57, but the similar usage of .as_ref() would not currently work in a const context, because it would require const traits (for Deref and AsRef), which are not yet stable. This is why I believe it is a non-blocker for providing impl AsRef<[T; N]> for [T; N] and should be discourages regardless of whether such an impl is going to be added.

Motivating examples or use cases

Originally brought up in rust-lang/rust#129849

Solution sketch

1. Implement a lint that warns about usages of .as_ref() & .as_mut() on arrays to mean .as_slice() & .as_mut_slice() respectively (and can automatically replace such usages). For the reasons outlined above, this part can be done regardless of whether AsRef<[T; N]> for [T; N] gets added.
2. Improve infrastructure initially introduced for IntoIterator for [T;N] to not assume Edition 2021 for arrays: rustc_skip_during_method_dispatch: decouple receiver & edition rust#129871
3. Provide impl AsRef<[T; N]> for [T; N] and impl AsMut<[T; N]> for [T; N], both marked to not be available through method call syntax until the next edition.
4. When the next edition rolls around, make the lint from the step 1 be applied automatically during cargo fix --edition.
5. [Optional]: implement a lint warning against using .as_ref() and .as_mut() when it results in automatic dereferencing. So that the potential future AsRef<T> for T won't run into as much code relying on suboptimal behavior.

Alternatives

Only do step 1 from the above or do nothing at all.
Pros: no APIs change, downstream code is not affected.
Cons: status quo is preserved.

Not providing this impl now means that all the work described here gets shifted to when (and if) Rust is eventually capable to provide AsMut<T> for T.

Links and related work

https://doc.rust-lang.org/edition-guide/rust-2021/IntoIterator-for-arrays.html
https://doc.rust-lang.org/edition-guide/rust-2024/intoiterator-box-slice.html

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.