I haven't been following every single update, so it's good to know that this constraint is no longer present (and has been gone for a bit).
foo.windows(2).map(|window| match window {
[l, r] => ...,
_ => panic!(...),
})...
foo.windows::<2>().map(|[l, r]| ...)...for &[l, r] in data.array_windows() {
let pages = posts.windows::<3>().map(|[prev, this, next]| Page {
item: this,
prev: Some(to_url(prev)),
next: Some(to_url(next)),
});
// then attach first and last pages32 seems so normal that it made me question why the default was 33, to include 0-32, but whatever heh. Glad to see this!
IIRC std and the compiler are built with the previous stable version of the compiler but with some special flag that allow using unstable features for bootstrapping.
Previous stable (0) compiles current source (1) into a temporary new stable (2), then (2) is used to compile (1) into the actual release version (3).
Could be wrong though, it has been a long time since I stumbled over a description of the release process.
#[derive(Copy, Clone, Debug)]
struct S {
a: [i32; 33],
}
(also as other commenters point out, std builtin types like Clone etc have already been supporting larger array sizes because of the standard library's ability to use unstable features, but before const generics were available as an unstable feature, that restriction very much did exist, and now crates from the ecosystem can use it too).
The article links to more details in that post [1], that's what the citation was from, sorry.
I thought it was conspicuous that they had '32' in the example because I remembered it as a limitation before.
No, arrays were not limited in length but IIRC generic types weren't able to make an array size generic across arbitrary counts.
[1] https://blog.rust-lang.org/2021/02/26/const-generics-mvp-bet...
func(a) func(a,b)
Etc... some languages have really weird bit :)