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`.
Added utils module with a `MaybeUninit` helper type to construct `[MaybeUninit<T>; N]`
Removed all uses of the "unstable-const-fn" feature, and documented it as being deprecated.
Changed `assert_capacity_limit` macro to work in const contexts.
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.
We were using &mut [u8] in encode_utf8, but this is not right according
to the developing unsafe coding guidelines. We need to use raw pointers
to write to possibly uninit memory.
We use a raw pointer form for encode_utf8. It was first attempted to
encapsulate the trusted-to-be-valid raw pointer in a simple { *mut u8,
usize } struct, but the current way of passing ptr and len separately
was the only way to not regress performance.
This impl maintains the same performance in arraystring benches.
Add exhaustive-style tests for encode_utf8
Using the following principles:
- Trivial methods (empty and simple constants) can be inline(always)
- Generic methods don't need any inlining directive at all.
..with the exception of Deref which just seems to be extra important.
- Non-generic items use #[inline] to enable inlining at the
compiler's discretion.
This is a nicer and simpler interface to expose, since the ref to uninit
array to pointer cast is not usable anyway (it's historic now, arrayvec
itself does not use it anymore).
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.
This is the "real" union solution, and ArrayString can use it since its
backing array is Copy. Unfortunately, we'll have to use the Copy bound
on the type, making it "viral" and visible in the user API.
* '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
We can't fix this properly (MaybeUninit with a union) until we change
the user visible API (we need to require that A: Copy.
As a temporary solution for arrayvec version 0.4.*, we use zeroed to
initialize an array of bytes, instead of using uninitialized. This may
have a negative performance impact, but the fix is to upgrade to future
arrayvec 0.5.
Instead of being vague about it, we can promise it.
We continue to be a bit vague in ArrayString::set_len. I don't see how
to add a char boundary check in ArrayString::set_len unfortunately.
It's a tricky issue, checking char boundaries requires reading the
memory of the string, and we don't even know if the user of set_len has
initialized that area of memory yet (but they hopefully did).
YuhanLiin