Feature Request: ArrayVec that is Copy

[mitchmindtree]

I'm considering using an ArrayVec<[_; 9]> as a small stack to keep track of pressed buttons on a mouse in conrod, however I noticed that it does not impl Copy. Seeing as it has a fixed-size, shouldn't deriving Copy be ok? Or is there some other boundary stopping this?

[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 part to be correct. The Copy case is simple, so a regular array is often enough.

[WiSaGaN]

Would you accept a CopyArrayVec pull-request?

[bluss]

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 you want, but maybe specialization (unstable feature) can be used to make ArrayVec Copy exactly when its elements are Copy.

[bluss]

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 non-ideal though.

[mitchmindtree]

This issue isn't very high priority for me, I'm happy waiting until specialization stabilises if that suits you best :+1:

[bluss]

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

[bluss]

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

[tbu-]

I'm not sure that this needs a breaking change.

[bluss]

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

[bluss]

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

[c410-f3r]

What is the status of this feature?

[smessmer]

Is this maybe easier to do now with the new array based implementation in 0.7?

[pwnorbitals]

I’d be interested in this feature, is #193 on the right way to be merged ? thanks :)