bluss

It's a relevant question. `ArrayVec` implements `Drop`, which precludes Copy. I have considered making a Copy-only ArrayVec, but most of the hard things this library does are for the non-Copy...

I'm not sure, it requires duplicating the whole thing. As said above, the most interesting things ArrayVec does is handle the non-Copy case correctly. I guess this is not what...

a PoC of copy-specialization works. This is the ideal approach since it transparently removes the overhead of non-copy arrayvecs (overwrite in drop etc). The use of unstable features is rather...

We don't even know if specialization will allow this, but we'll see.

It sounds like this is no longer just a question but a feature request?

arrayvec as a crate needs it. It's part of clearing the air before adding new features, if you will.

Where the most significant breaking change is the change of minimum Rust version

I agree -- this is not actually for the next version, just an upcoming version.

@Limeth I'd prefer to not do that, since it is useless -- it can't be used to impl `Array` for any array types, outside the crate.

@mqudsi The existing plan is that 1.0 is a good safety respecting version of the current functionality. That means ManuallyDrop/ManuallyUninit. Const generics is arrayvec 2.0.