1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
[](https://opensource.org/licenses/Zlib)
[](https://crates.io/crates/tinyvec)
[](https://docs.rs/tinyvec/)
# tinyvec
A 100% safe crate of vec-like types.
Not just safe at the public API boundary, fully safe for all internal code too: `#![forbid(unsafe_code)]`
The provided types are as follows:
* `ArrayVec` is an array-backed vec-like data structure. It panics on overflow.
* `SliceVec` is similar, but using a `&mut [T]` as the data backing.
* `TinyVec` (`alloc` feature) is an enum that's either an `Inline(ArrayVec)` or a `Heap(Vec)`.
If a `TinyVec` is `Inline` and would overflow its array it automatically transitions to `Heap` and continues whatever it was doing.
To attain this "100% safe code" status there is one compromise: the element type of the vecs must implement `Default`.
For more API details, please see [the docs.rs documentation](https://docs.rs/tinyvec/)
## `tinyvec` Alternatives?
Maybe you don't want to use `tinyvec`, there's other crates you might use instead!
* [arrayvec](https://docs.rs/arrayvec) is a crate with array-backed structures.
* [smallvec](https://docs.rs/smallvec) is a crate where the array-backed data can be moved to the heap on overflow.
The main difference is that both of those crates use `unsafe` code.
This mostly allows them to get rid of the `Default` limitation for elements that `tinyvec` imposes.
The `smallvec` and `arrayvec` crates are generally correct, but there's been occasional bugs leading to UB.
With `tinyvec`, any uncaught bugs *can't* lead to UB, because the crate is safe code all the way through.
If you want that absolute level of assurance against UB, use `tinyvec`.
|
