On Sat, Nov 9, 2013 at 12:43 AM, Kevin Ballard <[email protected]> wrote: > > Well no, you can't assume that the absence of a sigil means the absence of > heap storage. But for types that are possibly *not* stored on the heap, > such as str (which can be &'static str) and [T] (which can be a fixed-size > stack-allocated vector), the ~ is a useful distinction. > > -Kevin >
Slices are just a view into some block of memory and are truly a low-level building block without any incentive for reimplementation. Rust's built-in vector/string types lack allocator support, so alternate implementations will end up being created. There's also a need for small vectors/strings, and perhaps reference-counted slices. LLVM is a good example of a modern, performance-concious C++ project. Here are the approximate counts for the various vector types: ArrayRef: 1276 (fixed-size vectors aren't used through a C++11-style template, the number is probably 10k or 20k) std::vector: 3078 SmallVector: 5076 std::string: 3648 StringRef: 4596 SmallString: 493 C++11 also supports reference counted slices of memory via `std::shared_ptr`, but I'm unsure if LLVM uses a similar type. This would be the following set of types: * &[T] * [T, ..N] * Vec<T> * SmallVec<T, N> * &str * Str * SmallStr<T, N> * RcSlice<T> * RcMutSlice<T> With support for allocators like the C++ standard library, it's messier since Rust lacks default type parameters: * &[T] * [T, ..N] * Vec<T, A> * SmallVec<T, N, A> * &str * Str<A> * SmallStr<T, N, A> * RcSlice<T, A> * RcMutSlice<T, A> This is what I plan on implementing for rust-core, regardless of whether I convince anyone it's a good idea for the standard library.
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
