We can add arbitrary requested array sizes, if you need a lot of them they may be feature gated to not bloat the crate's default size too much, but ask away here!

So feel free to request sizes here; of course at some point in Rust's future we will have generics to cover this, and this kind of issue will be over!

When using NoDrop with no_drop_flag, there is no way to assert whether the inner value has been dropped or not. This PR exposes is_alive for containing structures that may also use unsafe_no_drop_flag themselves.

This implements serde support under the optional 'serde' feature, and adds unit tests to test said support.

Serde will be optionally included for runtime, but is unfortunately required for running tests - as cargo does not have support for optional dev-dependencies. FEATURES="serde" is added to the travis config, as serde-support tests will not run without it.

Fixes #54.

This is a cautious version of MaybeUninit, since we don't have one in libstd, based on ManuallyDrop.

This moves ArrayVec to a nice, no size overhead implementation by default. It is understood this is not a perfect solution! We do the best we can with stable Rust, and will adopt std's MaybeUninit or equivalent as soon as it becomes available.

ArrayString can already in this PR use what's been designated as the sound solution, since its backing array is Copy. See MaybeUninitCopy in the PR.

I think we can enable the future stable MaybeUninit equivalent conditionally, automatically, and don't need user visible API changes for that.

This removes nodrop as a dependency, finally.

Look here for previous discussion: https://github.com/bluss/arrayvec/pull/76#issuecomment-338380519

Closes #86 Fixes #62

I'm not sure if this is even possible but it would be great if ArrayVec::new() would be a const fn and hence could be called in places where only constant expressions are allowed (of course behind some feature-flag since const-fn is still unstable).

The reason I'd like this feature is that I work on embedded systems where it's typical to have all memory allocated statically, i.e. for a large buffer one would have something like

static mut BUFFER: [u8; 4096] = [0; 4096];

This works fine for arrays (and Copy types) but it would be great if I could also use an ArrayVec there. Again, not sure if it's even possible since mem::uninitialized() seems to not be a const-fn (although it should, I think) but maybe/hopefully I'm wrong. :)

lazy_static! will not work AFAIK because on first invocation of the initialization code the value gets constructed on the stack which typically will not be large enough to hold that value, even temporarily.

Thanks for considering this! :)

This add two new public methods on ArrayVec:

• extend_from_slice: extends the vector with a slice using a memcpy.
• capacity_left: utility function for use with extend_from_slice, e.g. see https://github.com/bluss/arrayvec/commit/fa4e22fcbfa73d63ad0dcaedfbc5542cc259210b.

This also changes the Write implementation to use extend_from_slice and another commit that removes some whitespace and empty lines.

ManuallyDrop is stable in Rust 1.20 (not yet released).

This is the official nodrop that arrayvec has been waiting a long time for; it's likely that we will use Rust 1.20 as the new required version from this point.

push, insert etc

With the goal of making arrayvec more of a "drop-in" for Vec, we realign the signatures methods .push(elt), .insert(index, elt) and .remove(index).

pub fn push(&mut self, element: A::Item);
pub fn insert(&mut self, index: usize, element: A::Item);
pub fn remove(&mut self, index: usize) -> A::Item;
pub fn swap_remove(&mut self, index: usize) -> A::Item;

try_push etc

Mimicing something like fallible allocation, we have the fallible new methods:

pub fn try_push(&mut self, element: A::Item) -> Result<(), CapacityError<A::Item>>;
pub fn try_insert(&mut self, index: usize, element: A::Item) -> Result<(), CapacityError<A::Item>>;

Notice that try_insert still panics if index is out of bounds.

pop_at etc

Mimicing .pop(), we have new “checked” versions of remove, swap_remove:

pub fn pop_at(&mut self, index: usize) -> Option<A::Item>;
pub fn swap_pop(&mut self, index: usize) -> Option<A::Item>;

The rationale is: indexing out of bounds is not a regular runtime error, it's normally a contract violation. So when we introduce checked versions of such API, then we get “checked” versions that return Option. Non-presence is not necessarily an error.

ArrayString::push etc

• ArrayString: push, push_str now have the same signature as corresponding on String. New methods try_push, try_push_str.

pub fn push(&mut self, c: char);
pub fn try_push(&mut self, c: char) -> Result<(), CapacityError<char>>;
pub fn push_str(&mut self, s: &str);
pub fn try_push_str<'a>(&mut self, s: &'a str) -> Result<(), CapacityError<&'a str>>;

Closes #46 Closes #45

Miscellaneous Changes

• odds is no longer a public dependency. We want the flexibility of dropping/upgrading this dep at will
• Rust version changes

Fixes #66

This seemed "too easy" as I basically copied stuff from libstd (with tweaks to the comments and slight tweaks to the code, noted in truncate.) So please let me know if I did anything wrong!

This changes the Index for zero-length Arrays to be (), ensuring that they are zero-sized. Additionally, this adds bool as the index for singleton Arrays, to become compatible with future enum optimisations, which could potentially make Option<ArrayVec<[u8; 1]>> be 16 bits long instead of 32 once more vigorous enum discriminant optimisations are implemented.

Some libraries like hex or bs58 expect a pre-filled buffer to operate on but ArrayString does not have an infallible constructor to create a fully filled inner array with "whatever".

For example, the following made use of from_byte_string to make everything work as expected:

let mut buffer = ArrayString::from_byte_string(&[b' '; SOME_LEN]).unwrap();
let len = bs58::encode(some_data).into(&mut buffer[..]).unwrap_or_default();
buffer.truncate(len);

So do you mind me providing a PR to create something like ArrayString::new_filled()?

We can use compile-time asserts to check that LEN <= CAP, and then only initialize the first LEN elements. So something like

impl<T, const LEN: usize, const CAP: usize> From<[T; LEN]> for ArrayVec<T, CAP> {
  fn from(arr: [T; LEN]) -> Self {
    assert!(LEN <= CAP);
    // duplicate the rest of From<[T; LEN]> for ArrayVec<T, LEN> here
  }
}

👋 Hello @bluss! Thank you for making this crate; it's super useful.

I don't think we can dereference an ArrayString into a &str in a constant function right now, and traits like Deref seem unlikely to become const in the near future. Do you have an idea of the best way to support ArrayString -> string coercion in const functions?

One way would just be to add a new method on ArrayString. I've done that in this PR in case it would be helpful; otherwise, let me know if you prefer me to open an issue for this.

Example:

/// Return a mutable slice containing all elements of the vector.
pub fn as_mut_slice(&mut self) -> &mut [T] {
    ArrayVecImpl::as_mut_slice(self)
}

AFAIK, const trait implementation is not landing soon. If ArrayVecImpl::as_mut_slice is defined via the call to the inherent function instead (i.e. if we reverse the implementation dependency), it will be possible to have easier feature-gated support for the const inherent associated function. Instead of the dependence on both const_trait_impl and const_mut_refs features there will be the dependency only on the latter.

I guess it may be fine if you don't want to offer a feature-gated support for nightly const_mut_refs. However, I wouldn't mind to help you with reversing the dependency and opt-in support for the aforementioned nightly features. There's a popular crate const_fn that can help provide such support cleaner.

Is there any reason why having a const ArrayVec::new would be worse?

Follow up question: should ArrayVec::new_const be deprecated, removed completely or [the option that I so far oppose] left as is?

This change adds Natvis visualizations for ArrayVec and ArrayString to help improve the debugging experience on Windows.

Natvis is a framework that can be used to specify how types should be viewed under a supported debugger, such as the Windows debugger (WinDbg) and the Visual Studio debugger.

When debugging types such as ArrayVec and/or ArrayString under a Windows debugger, the entries for these data structures are not always clear upon first glance. The internal data structure is shown, and it's not presented in a user-friendly way. The Rust compiler does have Natvis support for some types, but this is limited to some of the core libraries and not supported for external crates.

https://github.com/rust-lang/rfcs/pull/3191 proposes adding support for embedding debugging visualizations such as Natvis in a Rust crate. This RFC has been approved, merged and implemented.

This PR adds:

Natvis visualizations for both ArrayVec and ArrayString. Tests for testing visualizers embedded in the arrayvec crate. Updates to the CI pipeline to ensure tests for visualizers are run so they do not break silently. A new debugger_visualizer feature for the arrayvec crate to enable the unstable debugger_visualizer Rust feature.