[−][src]Crate tinyvec
Programmers can have a little vec, as a treat.
What This Is
This crate is a 100% safe code alternative 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 implementDefaultto be usable in these vecs. For some people that's an absolute deal-breaker, and if so I understand. However, quite a few types have aDefaultimpl, so I think that for a lot of common cases you can use these vecs. ArrayVecis an array-backed vec-like where all slots are "live" in the Rust sense, but the structure tracks what the intended length is as you push and pop elements and so forth. If you try to grow the length past the array's capacity it'll error or panic (depending on the method used).- (Note: I am very sorry that this type has the same name as the
ArrayVectype in thearrayveccrate. We really couldn't think of another name for this sort of data structure. Please contact us with a better name before this crate is 1.0 if you can think of one.)
- (Note: I am very sorry that this type has the same name as the
TinyVecis an enum that's either an "inline"ArrayVecor a "heap"Vec. If it's in array mode and you try to grow the vec beyond it's capacity it'll quietly transition into heap mode for you and then continue operation. This type is naturally behind theallocfeature gate.
Stability Goal
The crate is still in development, but we have some very clear goals:
- The crate is 100% safe code. By this I don't mean a totally safe API, I
mean no
unsafeinternals either.#![forbid(unsafe_code)].- We do use
coreandallocof course, which provide a safe API overunsafeoperations. However, if you don't at least trust those crates then you've got bigger problems on your hands.
- We do use
- No required dependencies.
- We might of course provide optional dependencies for extra
functionality (eg:
serdecompatability), but none of them will be required. I hate dependencies even more than you do.
- We might of course provide optional dependencies for extra
functionality (eg:
- The intended API is that, as much as possible, these types are
essentially a "drop-in" replacement for the standard
Vectype.- For
Vecmethods that are not yet Stable, they are sometimes provided via a crate feature, in which case the feature requires Nightly of course. - If
Vecmethods that are stable but which rely on an unstable library internal, that also requires a feature and a nightly compiler (sorry). - Some of the methods provided are not part of the
VecAPI but are none the less important methods to have. In this case, the method names are usually fairly long and perhaps even a little silly. It is the hope that this "convention" will prevent any potential name clash between our vec types and the standardVectype. - That said, I'm not one of those "never 2.0" people, so if
Veclands some method with the same name as something we have, we'll just bite the bullet and fix it with a breaking change.
- For
Macros
| array_vec | Helper to make an |
| tiny_vec | Helper to make a |
Structs
| ArrayVec | An array-backed vector-like data structure. |
| ArrayVecDrain | Draining iterator for |
| ArrayVecIterator | Iterator for consuming an |
| TinyVecDrain | Draining iterator for |
Enums
| TinyVec | A vector that starts inline, but can automatically move to the heap. |
| TinyVecIterator | Iterator for consuming an |
Traits
| Array | A trait for types that can be the backing store of an
|