wasmtime / issue #14832 Typed map<K, V> support is limite... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #14832 Typed map<K, V> support is limite...

Wasmtime GitHub notifications bot (Oct 19 2026 at 19:13):

Today map<K, V> can only be used through the typed API and bindgen! as HashMap<K, V> with the default hasher (std's RandomState, or hashbrown's default hasher without std). A few consequences:

There's no support for BTreeMap, custom hashers, or getting at the raw entries. Vec<(K, V)> doesn't work since it only typechecks against list.

bindgen! has no way to choose the type (no map_type option, and with doesn't apply to map aliases).

additional_derives: [Hash] (or Ord) fails for any record containing a map.

Lowering iterates a randomly-seeded HashMap, so the order of entries the guest sees changes from run to run, which is surprising for embedders following the deterministic-execution guide.

Lifting deduplicates with last-wins semantics, which is where #14812 comes from.

For comparison, guest-side wit-bindgen has a map_type option plus a small WitMap trait, with BTreeMap as the no_std-friendly default and HashMap available behind std. Would something similar make sense here: impls for BTreeMap and HashMap<K, V, S>, an entries-preserving type for "just give me the list", and a bindgen! option to pick between them?

Wasmtime GitHub notifications bot (Oct 19 2026 at 19:21):

alexcrichton added the wasm-proposal:component-model-map label to Issue #14832.

Wasmtime GitHub notifications bot (Oct 22 2026 at 20:31):

fitzgen closed issue #14832:

Today map<K, V> can only be used through the typed API and bindgen! as HashMap<K, V> with the default hasher (std's RandomState, or hashbrown's default hasher without std). A few consequences:

There's no support for BTreeMap, custom hashers, or getting at the raw entries. Vec<(K, V)> doesn't work since it only typechecks against list.

bindgen! has no way to choose the type (no map_type option, and with doesn't apply to map aliases).

additional_derives: [Hash] (or Ord) fails for any record containing a map.

Lowering iterates a randomly-seeded HashMap, so the order of entries the guest sees changes from run to run, which is surprising for embedders following the deterministic-execution guide.

Lifting deduplicates with last-wins semantics, which is where #14812 comes from.

For comparison, guest-side wit-bindgen has a map_type option plus a small WitMap trait, with BTreeMap as the no_std-friendly default and HashMap available behind std. Would something similar make sense here: impls for BTreeMap and HashMap<K, V, S>, an entries-preserving type for "just give me the list", and a bindgen! option to pick between them?

Last updated: Oct 31 2026 at 23:03 UTC