Support GenericArray for IntoBytes

[vadixidav]

Currently, if you attempt to use GenericArray (see https://docs.rs/generic-array/1.1.0/generic_array/) with a fixed array size, even if the element stored in the array is both IntoBytes and Unaligned, the IntoBytes derive does not work. Given that GenericArray is repr(transparent) over a standard array, I think it should work the same as a standard array and derive properly if the correct conditions are met.

It seems like this behavior might need to go into GenericArray, in which case I can submit an issue there, but I wanted to submit the issue here to see if I might be missing something. I figured that since it was repr(transparent) that zerocopy would be able to interrogate the type information in some way, which the docs mention.

The reason why this is important is that if you instantiate an actual generically sized array <const N: usize> -> [T; N], then it infects both your API and any user downstream that wishes to be generic over any part of the array length with a bound where [T; N]:, which fundamentally limits expressiveness by making certain patterns impossible. Due to this, the typical pattern of usage is to use generic_array::GenericArray with const generics these days.

Ideally my goal would be to use exclusively repr(packed) for everything, which should extend to the GenericArray array directly due to repr(transparent). Let me know if I just need to file an issue on generic-array's github instead.

[joshlf]

This sounds like something that would be awesome to support. It's not clear whether we should support this or whether generic-array should support this, and the design space is somewhat complex. We don't have time to work on this right now, but we intend to follow up on it eventually.

---

Some thoughts from discussing this with @jswrenn:

• generic-array's internals involve very gnarly type-level programming; idiomatic integration of zerocopy's traits there might be difficult or impossible
• We don't have a good story around multi-version support of zerocopy traits in public APIs (see Make derive macros hygienic #11)
• GenericArray does have (or could easily have) sufficient safety invariants to permit zerocopy to manually implement our traits for it
• In contrast, generic-array can't implement our traits without creating a semver hazard, particularly in the case of KnownLayout
• They could possibly derive our traits rather than implement them manually
• On the other hand, generic-array might benefit from using zerocopy internally to get rid of unsafe
• Whatever we do, we need to avoid the risk of a future circular dependency (e.g. if we want to use GenericArray to support Support operations on byte arrays #248)

[vadixidav]

To avoid a circular dependency, it may be necessary to split out any traits or components an upstream library would use into a separate crate if generic-array would need to implement the traits itself (perhaps zerocopy-traits or zerocopy-core). If you intend to add generic-array impls directly into zerocopy (which you mentioned is difficult), then it would not be necessary for you to split it into separate crates. It sounds like the best thing to do here is probably to let generic-array do the implementation, but that would require some changes in zerocopy before it would be possible to do that in a way that avoids circular dependencies.