Stock WinRT collection types backed by Rust containers.
- 📦 crates.io
- 📖 docs.rs
- 🚀 Getting started
- 📁 Source
windows-collections provides ready-made implementations of the WinRT collection
interfaces — IIterable, IVector, IVectorView, IMap, and IMapView — so
you can hand a Rust Vec or BTreeMap to an API that expects a WinRT collection.
The remainder of this page covers how the crate is built and maintained. It is
for contributors and is not needed to use windows-collections.
src/bindings.rs is generated by tool_bindings from
crates/tools/bindings/src/collections.txt; the collection adapters are
hand-written. Used internally by the windows crate.
Iterating a collection (for x in &vector) yields through BufferedIterator
(src/buffered_iterator.rs), which fetches elements a block at a time via
GetMany rather than one IIterator::next ABI call per element. windows-bindgen
generates the IntoIterator impls that reference it. The block is sized to keep
the buffer near 2 KB regardless of element size.
This batching applies to maps too: IMap/IMapView/IObservableMap implement
IIterable<IKeyValuePair<K, V>>, so for pair in &map drives the same
BufferedIterator (yielding IKeyValuePair items) — there is no separate, slower
map path. A map iteration still costs more than a vector of scalars, but not because
of the iterator: GetMany over IVector<Int32> bulk-copies the values inline,
whereas over a map it returns a block of IKeyValuePair COM objects (one AddRef
each) and reading every pair.Value()/Key() remains a per-pair ABI crossing — the
IMap ABI offers no bulk key/value read. Separately, the component-side stock map
iterator snapshots its entries once at First() so each step is O(1) rather than
re-walking the tree, keeping a full traversal linear.
Run cargo test -p windows-collections; see also the workspace test crates.