Stream: git-wasmtime

Topic: wasmtime / issue #7701 Implement `Lower` and `Lift` for `...

Wasmtime GitHub notifications bot (Dec 21 2023 at 10:24):

rvolosatovs edited issue #7701:

Feature

Refs https://github.com/bytecodealliance/wasmtime/issues/7676 #7680 #7688
Suggestion is to implement the get_typed_func param/return bounds (i.e. ComponentNamedList, Lower and Lift) on wasmtime::component::Val, such that one could bind the lengths of params/results, while still (partially) using the "polymorphic" types.

Benefit

This would get us one step closer to a more type-safe and possibly more efficient approach for invoking guest Wasm functions, for which WIT is not known at compile-time, i.e. no bindings exist.

This would allow "partial bounds" on the function signatures exported by the Wasm, e.g.:

(u32, wasmtime::component::Val, wasmtime::component::ResourceAny) -> (wasmtime::component::Resource<T>)

Could be a valid function type bound, where the type of the second parameter could only be determined at runtime, for example, by inspecting the WIT embedded in the Wasm component executed.

Implementation

It feels like most of the functionality already exists, just not the trait implementations:
https://github.com/bytecodealliance/wasmtime/blob/e6a9fa19a2609213ce87a4fed40ab102ba83fa29/crates/wasmtime/src/component/values.rs#L623-L913

Alternatives

Developers could use e.g. Rust macros to generate an implementation of a polymorphic Call trait for all possible signatures of exported component functions, which would be a lot of hard-to-maitain work, otherwise they could use untyped func directly

Wasmtime GitHub notifications bot (Dec 21 2023 at 10:25):

rvolosatovs edited issue #7701:

Feature

Refs https://github.com/bytecodealliance/wasmtime/issues/7676 #7680 #7688
Suggestion is to implement the get_typed_func param/return bounds (i.e. Lower and Lift) on wasmtime::component::Val, such that one could bind the lengths of params/results, while still (partially) using the "polymorphic" types.

Benefit

This would get us one step closer to a more type-safe and possibly more efficient approach for invoking guest Wasm functions, for which WIT is not known at compile-time, i.e. no bindings exist.

This would allow "partial bounds" on the function signatures exported by the Wasm, e.g.:

(u32, wasmtime::component::Val, wasmtime::component::ResourceAny) -> (wasmtime::component::Resource<T>)

Could be a valid function type bound, where the type of the second parameter could only be determined at runtime, for example, by inspecting the WIT embedded in the Wasm component executed.

Implementation

It feels like most of the functionality already exists, just not the trait implementations:
https://github.com/bytecodealliance/wasmtime/blob/e6a9fa19a2609213ce87a4fed40ab102ba83fa29/crates/wasmtime/src/component/values.rs#L623-L913

Alternatives

Developers could use e.g. Rust macros to generate an implementation of a polymorphic Call trait for all possible signatures of exported component functions, which would be a lot of hard-to-maitain work, otherwise they could use untyped func directly

Wasmtime GitHub notifications bot (Dec 22 2023 at 00:12):

alexcrichton commented on issue #7701:

I originally didn't implement this because Lift and Lower inherit from ComponentType which didn't have a way to type-check since &self wasn't taken in the typecheck method. That being said nowadays the type is passed through Lift::lift and Lower::lower so this should actually be possible to do nowadays by returning "true" from any call to typecheck and then performing the actual type check at runtime in the lift and lower methods.

I think this'd be a great idea to implement as well, thanks for filing an issue!

Wasmtime GitHub notifications bot (Dec 22 2023 at 00:12):

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

Last updated: Dec 06 2025 at 06:05 UTC