#vec #no-std #no_std #smol

no-std tinyvec

Just, really the littlest Vec you could need. So smol.

9 unstable releases (3 breaking)

✓ Uses Rust 2018 edition

new 0.3.3 Mar 26, 2020
0.3.2 Jan 30, 2020
0.2.0 Jan 14, 2020
0.1.2 Jan 12, 2020
0.0.0 Jan 7, 2020

#186 in Data structures

Download history 48/week @ 2020-01-06 52/week @ 2020-01-13 72/week @ 2020-01-20 30/week @ 2020-01-27 65/week @ 2020-02-03 165/week @ 2020-02-10 261/week @ 2020-02-17 219/week @ 2020-02-24 188/week @ 2020-03-02 115/week @ 2020-03-09 470/week @ 2020-03-16

719 downloads per month
Used in 4 crates (3 directly)

Zlib license

1.5K SLoC

License:Zlib Minimum Rust Version travis.ci AppVeyor crates.io docs.rs



A 100% safe crate of vec-like types.

For details, please see the docs.rs documentation


Programmers can have a little vec, as a treat.

What This Is

This crate provides 100% safe code alternatives to both arrayvec and smallvec.

Being 100% safe means that you have to have some sort of compromise compared to the versions using unsafe. In this case, the compromise is that the element type must implement Default to be usable in these vecs. However, that still allows you to use quite a few types, so I think that you'll find these vecs useful in many cases.

  • ArrayVec is an array-backed vec-like structure with a fixed capacity. If you try to grow the length past the array's capacity it will error or panic (depending on the method used).
  • (alloc feature) TinyVec is an enum that's either an "Inline" ArrayVec or a "Heap" Vec. If it's Inline and you try to grow the ArrayVec beyond its array capacity it will quietly transition into Heap mode and then continue the operation.

Crate Goals

  1. The crate is 100% safe code. Not just a safe API, there are also no unsafe internals. #![forbid(unsafe_code)].
  2. No required dependencies.
    • We might provide optional dependencies for extra functionality (eg: serde compatibility).
  3. The intended API is that, as much as possible, these types are essentially a "drop-in" replacement for the standard Vec type.
    • Stable Vec methods that the vecs here also have should be the same general signature.
    • Unstable Vec methods are sometimes provided via a crate feature, but if so they also require a Nightly compiler.
    • Some methods are provided that are not part of the Vec type, such as additional constructor methods. In this case, the names are rather long and whimsical in the hopes that they don't clash with any possible future methods of Vec.
    • If, in the future, Vec stabilizes a method that clashes with an existing extra method here then we'll simply be forced to release a 2.y.z version. Not the end of the world.
    • Some methods of Vec are simply inappropriate and will not be implemented here. For example, ArrayVec cannot possibly implement from_raw_parts.

No runtime deps