Project future post-1.51.0 and min_const_generics, possible deprecation?

[novacrazy]

Now that min_const_generics has been stabilized in Rust 1.51.0, should we begin deprecating this crate? We can use the existing build.rs script to check the version number and only generate the deprecation on post-1.51.0 versions.

However, an alternative would be to port much of this crate's functionality to a new (simpler) array wrapper type that fully utilizes const generics, to work alongside and ease replacement of existing code.

Please feel free to submit your thoughts on the matter.

[burdges]

There are tricks folks play with this crate that do not work with min_const_generics, but one expects this crate incurs a larger compile time penalty, so..

I'd think changes here sound painful, but ideally generic_array users should transition themselves to min_const_generics if possible, and especially remove generic_array from public interfaces.

[novacrazy]

When I have time and people desire it, I could attempt a separate crate with a (mostly) drop-in GenericArray type with the signature:

pub struct GenericArray<T, const N: usize>([T; N]);

and implement most/all of the existing GenericArray functionality on that.

If a user has typenum deeply ingrained in their project already, it would be trivial to adapt to const-generics, via: NewGenericArray<T, { N::USIZE }>

[ilyvion]

Came across a use-case today that doesn't work with min_const_generics but does work with generic-array. Had a user come into the Rust discord and ask why this isn't possible:

trait Trait {
    const N: usize;
    fn foo() -> [f32; Self::N];
}

We couldn't really explain why Rust won't accept this, but it was argued that you'd sometimes want it to be an associated const, not a const generic, because—just like with associated types—you want only one implementation of this trait per type. Rust is having none of it:

error: generic parameters may not be used in const operations
 --> src/lib.rs:3:23
  |
3 |     fn foo() -> [f32; Self::N];
  |                       ^^^^^^^ cannot perform const operation using `Self`
  |
  = note: type parameters may not be used in const expressions

Which seems a bit off to me, since I would like to draw a parallel to associated types, which you can use in that manner. generic-array to the rescue, however, as this works just fine:

use generic_array::{ArrayLength, GenericArray};
trait Trait {
    type N: ArrayLength<f32>;
    fn foo() -> GenericArray<f32, Self::N>;
}

So that's one reason to keep the old way around. At least I suspect that if GenericArray was changed to GenericArray<T, const N: usize> we'd be back at square one with regard to this use-case.

The motivating example compiles with #![feature(generic_const_exprs)] though, so if/when that stabilizes, this particular use-case falls away.

[novacrazy]

Revisiting this two years later, const-generics are still too minimal to fully replace generic-array. However, with #137 just now we have the opportunity to make generic-array 1.0 much more ergonomic overall. For anyone watching this issue, please suggest any additional breaking changes in #101

Will consider reopening if Rust ever has full const-generic support.

[burdges]

I wish generic-array occurred less in public interfaces. It still delivers poor ergonomics, even if multiple types never occur.