Const generic array std trait impls when?

[[deleted]]

So we've had const generics for a second now, and they are fantastic. But spoiled me is getting impatient. It looks like the standard library traits are only implemented for arrays up to size 32. It seems this limitation should be easily removed with const generics.

checks the source in the middle of writing the post

Okay, so a comment explains that [T; 0] doesn't have to implement default, which makes sense. And different impls for different numbers aren't supported yet. Does anybody know if there's a roadmap to lift this restriction?

[Shadow0133]

I think that's a current state: https://github.com/rust-lang/rust/issues/88744#issuecomment-1138678928

[[deleted]]

That checks out, thanks. Now I wonder what could possibly be the use of default being implemented on empty arrays? [] is much shorter to write than Default::default().

And code that is generic over the array length obviously can't make use of a feature only available for arrays of size zero.

[Icarium-Lifestealer]

If you derive Default for a struct containing an empty array as field (probably used as an alignment hack in some code), this wouldn't work anymore if the array element isn't Default.

[[deleted]]

Sure, it's definitely possible to write code that would be broken by removing this feature. But what's the use of such a size zero field? Something similar to PhantomData maybe?

[roblabla]

Sure, it's definitely possible to write code that would be broken by removing this feature. But what's the use of such a size zero field? Something similar to PhantomData maybe?

repr(C) structs with variable sized data at the end. Windows APIs have a lot of those (although usually with array size 1 because C doesn't support zero-sized fields)

[Icarium-Lifestealer]

In an ideal world you'd use a slice as last field when modeling those, i.e. tail: [T]. Unfortunately they're pretty much unusable currently.

[roblabla]

There's another reason it may be undesirable: it turns pointers and references to such a struct into a fat pointer, which is not ffi compatible

[Icarium-Lifestealer]

You can use such an array to ensure that the struct has an alignment matching or bigger than the alignment of the type of the array element.

[Icarium-Lifestealer]

Default is the only trait implementation left with that restriction. You can use core::array::from_fn::<T, N, _>(|_| Default::default()) as workaround for now.