Skip to content
CryoCryo home
StdlibFoundations

collections

Six containers, all built on alloc and all generic over the allocator with a GlobalAlloc default. Each owns heap storage and exposes drop(mut &this); the compiler synthesises the call at scope exit.

public module collections::raw_buffer;
public module collections::array;
public module collections::str;
public module collections::string;
public module collections::hashmap;
public module collections::hashset;
public module collections::pair;
FileWhat it holdsImport
arrayArray<T, A>, the growable contiguous sequence(prelude)
strStr, the borrowed UTF-8 viewimport std::collections::str;
stringString<A>, owned growable UTF-8import std::collections::string;
hashmapHashMap<K, V, A>, separate chainingimport std::collections::hashmap;
hashsetHashSet<T, A>, over HashMap<T, ()>import std::collections::hashset;
pairPair<A, B>, the owned two-element tupleimport std::collections::pair;
raw_bufferRawBuffer<T, A>, the untyped backing store String is built onimport std::collections::raw_buffer;

A note on Copy-gated methods

Several methods across these containers carry a where T: Copy bound — get, iter, append, resize. The reason is the same every time: they hand back an independent bitwise duplicate while the container still owns the stored element. That is only sound when T has no drop obligation; otherwise both copies would own the same heap buffer and both would free it.

For an owning element type, reach for the borrowing counterpart instead: get_ref rather than get, iter_ref rather than iter, entries / keys_ref / values_ref on a map. Those hand out pointers, never copies, and are sound for every T.

A second family of bounds, where T: Drop, appears on the methods that discard elements — set, truncate, clear, remove on a map. Every type satisfies it (a POD type's drop lowers to nothing), so it restricts nothing; it is what lets the container run T::drop on the elements it throws away instead of leaking them.