arrayvec 1.0

[bluss]

Planning for arrayvec 1.0

Prerequisites:

• [x] ~Stable Manually Drop (Rust 1.20!)~
• [x] #127 Use ManuallyDrop if safe, else wait for stable MaybeUninit or equivalent union code
• [x] With good model for why keeping uninitialized data in arrayvec is safe.
• [x] Settle API issues (Result vs Option and when to panic) in #61 #163
• [x] Const generics #172

[johncf]

Please consider releasing a 0.4 after settling API issues raised in #45 and #46, before 1.0. Would you like a PR?

[bluss]

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

[Limeth]

It might be worth considering #[macro_export]ing the fix_array_impl_recursive macro, too.

[bluss]

@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]

With RFC2000 approved, I would hold off on a 1.0 until support for that lands in nightly. It can make this a zero-cost crate and provide compile-time overflow safety. The API will most definitely break, which is why I recommend not doing 1.0 until then (you'll be able to specify the length as a generic parameter, i.e. ArrayVec<u8, 20>).

https://github.com/rust-lang/rfcs/blob/master/text/2000-const-generics.md

[bluss]

@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.

[Luro02]

It would be useful, if you could create a github milestone and tag all the issues 🤗

[bluss]

Since we've been so slow to actually push out 1.0, const generics has now landed before 1.0 happened. So now it can be on the checklist. But we have every item ticked off, now.