The new() function is significantly faster, it optimizes better at the
moment/in current rust. For this reason, provide a const fn constructor,
but not as the default `new`.
Store the length as u32 internally. This is to shrink the size of the
ArrayVec value (when possible, depending on element type).
Inline storage vectors larger than u32::MAX are very unlikely to be
useful - for these cases, prefer using Vec instead.
It's not possible to have the CAP type parameter be of type u32 (missing
features in const evaluation/const generics). We also have to panic at
runtime instead of having a static assertion for capacity, for similar
reasons.
This regresses performance of the .extend(s) benchmark where s is a
slice; to compensate add a private extend_from_slice method that we can
use where possible (clone_from, try_from).
This is very useful for generic code that may want to parse arbitrary
input string into arbitrary other types.
Limitations of the FromStr trait don't allow us to keep the original string slice
inside the CapacityError, unfortunately.
* '0.4' of https://github.com/bluss/arrayvec:
0.4.9
TEST: Add test that ensures the MaybeUninit impl is used on nightly
FIX: Remove use of uninitialized in ArrayString
FEAT: Implement a "MaybeUninit" and use it conditionally
TEST: Add test that Some(ArrayVec<[&_;_]>).is_some()
MAINT: Test the 0.4 branch in travis
In the test, test with Vec first to see how Rust implements panic
recovery while elements drop. If Vec drops all the elements, then we
test that arrayvec does too.
- Add try_insert / try_remove to be the old fallible variants that
return errors
- Insert that pushes out if full does no longer exist -- full vec is an
error
What the test was doing was simply UB and we can't expect rustc to make
sense of it. The test was failing with optimizations on, yet a closer look
says arrayvec is still working as it should. So remove the broken test.