For core wasm Wasmtime offers the Func and TypedFunc APIs for calling into WebAssembly. The current intention is to provide the same for the component model. Currently the TypedFunc API exists, but the Func API doesn't actually support calls.
The intended use case for this feature is for something like the wasmtime CLI where it wants to be able to call any component it loads so we can't statically enumerate the signatures ahead of time. It's expected that this version of calling a component is slower (perhaps significantly so) than calling a typed function.
Currently I don't have many ideas about how the implementation will be done. The rough idea is that there'd be some sort of wasmtime::Val equivalent but for the component model. Like with Val the actual value iteslf is "tagged" with the type information. The actual implementation of this is going to be much trickier than core wasm because Val only deals with primitives and a component model value can recursively contain other component model values. This will likely imply a significant overhead in terms of allocations, indirection, and management.
I do not think that the wasmtime::component::Val type will implement any of ComponentValue, Lift, or Lower. Those are intended only for types where the type in the component model is statically known at compile-time.
This work is also motivated by unlocking half of the fuzzing possiblities in #4307
For core wasm Wasmtime offers the
FuncandTypedFuncAPIs for calling into WebAssembly. The current intention is to provide the same for the component model. Currently theTypedFuncAPI exists, but theFuncAPI doesn't actually support calls.The intended use case for this feature is for something like the wasmtime CLI where it wants to be able to call any component it loads so we can't statically enumerate the signatures ahead of time. It's expected that this version of calling a component is slower (perhaps significantly so) than calling a typed function.
Currently I don't have many ideas about how the implementation will be done. The rough idea is that there'd be some sort of
wasmtime::Valequivalent but for the component model. Like withValthe actual value iteslf is "tagged" with the type information. The actual implementation of this is going to be much trickier than core wasm becauseValonly deals with primitives and a component model value can recursively contain other component model values. This will likely imply a significant overhead in terms of allocations, indirection, and management.I do not think that the
wasmtime::component::Valtype will implement any ofComponentValue,Lift, orLower. Those are intended only for types where the type in the component model is statically known at compile-time.This work is also motivated by unlocking half of the fuzzing possiblities in #4307