Change:
unsafe { &mut *(s as *mut T).cast::<[T; 1]>() } } <del> /// Utility trait implemented only on arrays of fixed size /// /// This trait can be used to implement other traits on fixed-size arrays /// without causing much metadata bloat. /// /// The trait is marked unsafe in order to restrict implementors to fixed-size /// arrays. A user of this trait can assume that implementors have the exact /// layout in memory of a fixed size array (for example, for unsafe /// initialization). /// /// Note that the traits [`AsRef`] and [`AsMut`] provide similar methods for types that /// may not be fixed-size arrays. Implementors should prefer those traits /// instead. #[unstable(feature = "fixed_size_array", issue = "27778")] pub unsafe trait FixedSizeArray<T> { /// Converts the array to immutable slice #[unstable(feature = "fixed_size_array", issue = "27778")] fn as_slice(&self) -> &[T]; /// Converts the array to mutable slice #[unstable(feature = "fixed_size_array", issue = "27778")] fn as_mut_slice(&mut self) -> &mut [T]; } #[unstable(feature = "fixed_size_array", issue = "27778")] unsafe impl<T, A: Unsize<[T]>> FixedSizeArray<T> for A { #[inline] fn as_slice(&self) -> &[T] { self } #[inline] fn as_mut_slice(&mut self) -> &mut [T] { self } } </del> /// The error type returned when a conversion from a slice to an array fails. #[stable(feature = "try_from", since = "1.34.0")] #[derive(Debug, Copy, Clone)]

Discussion:
This is a tracking issue for the unstable feature in the standard library. This is likely to be deprecated and removed in favor of generic integers one day, and in the meantime there are not many consumers of it.
Note that the feature specifically covers the trait. There's some other code in core::array, but it's all implicitly stable.
The FixedSizeArray trait would be great, except for many uses the ranges of sizes it's implemented for simply isn't what you need, and there is no way to expand it. Thus it is mostly useless in the current form.
Could the compiler magically have an "infinite" (generated on demand) number of impls of ? If that happens and the type parameter is made into an associated type (and maybe an associated const for the size is ), then most of the other impls that currently only go up to N=32 could be made generic .
If/when the issue of using associated consts like consts is resolved, that is, allow to compile; then an infinite number of FixedSizeArray impls would give us the same thing as generic integer parameters. This suggests to me that completing associated constants is basically the same problem as allowing generic integer parameters.
for now could be moved to a crate since it doesn't use any compiler magic anyway
has a similar trait, called :
Triage: no changes
Something did change in this trait is now implemented for all sizes: The trait is also unstable:
I wrote about extending and stabilizing this trait.
This trait isn't used anywhere and doesn't seem to be needed any more now that we have const generics. fcp close
Team member has proposed to close this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [x] [x] 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 for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to close, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.