arrayvec

arrayvec provides ArrayVec and ArrayString, vector-like and string-like containers backed by a fixed-size array instead of the heap. Because the capacity is bounded at compile time and storage lives inline, these types can be used in no_std environments, embedded firmware, and any hot path where heap allocation is undesirable or unavailable.

The crate mirrors the standard library’s Vec/String APIs closely, so adopting it is largely a drop-in change: push, pop, extend, slicing, and iteration all behave the way Rust developers already expect, just with a hard capacity ceiling enforced at runtime.

What You Get

• ArrayVec<T, N> — a Vec-like container backed by a fixed-size array with no heap allocation
• ArrayString<N> — a String-like UTF-8 buffer with fixed capacity
• Optional serde, borsh, and zeroize integrations behind feature flags
• Full no_std support for embedded and kernel-level code
• Familiar Vec/String-style API surface (push, pop, extend, drain, slicing) for near drop-in adoption

Common Use Cases

• Embedded and no_std firmware where dynamic heap allocation isn’t available
• Hot-path code that wants to avoid allocator overhead for small, bounded collections
• Building small string buffers with a known maximum length without heap churn
• Serializing fixed-size buffers with serde/borsh in performance-sensitive services

Under The Hood

Architecture - The crate centers on ArrayVec<T, N> (src/arrayvec.rs) and ArrayString<N> (src/array_string.rs), both wrapping a [MaybeUninit<T>; N]-style inline buffer plus a length field; arrayvec_impl.rs factors out shared push/pop/insert/remove logic used by both types so growth-at-capacity and bounds behavior stay consistent. There is no dynamic backing store — all capacity is fixed at the type level via const generics, which is what allows no_std operation.

Tech Stack - Pure Rust, edition 2018, minimum supported Rust version 1.51, zero mandatory dependencies. Optional integrations (serde, borsh, zeroize) are gated behind Cargo features and only pulled in when a downstream crate opts in, keeping the default dependency footprint at zero.

Code Quality - The crate carries an extensive tests/ suite (tests.rs, serde.rs, borsh.rs, plus generated codegen tests) exercising boundary conditions like at-capacity pushes and UTF-8 edge cases in ArrayString. Given the use of raw unsafe blocks (~35 occurrences) to manage uninitialized memory manually, the project relies on Miri/UB-checking CI and careful invariant documentation rather than safe-Rust-only guarantees — appropriate for a low-level primitives crate but worth noting for auditors.

API Design - The public API deliberately mirrors std::vec::Vec and std::string::String method names and semantics (push, pop, extend, drain, try_push for fallible insertion), which minimizes the learning curve for anyone already familiar with the standard library and makes swapping between heap-backed and stack-backed collections mostly mechanical.