Stream: git-wasmtime

Topic: wasmtime / issue #7701 Implement `ComponentNamedList`, `L...

Wasmtime GitHub notifications bot (Dec 18 2023 at 14:48):

rvolosatovs opened 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::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 18 2023 at 14:48):

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) use 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::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 18 2023 at 14:50):

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) use 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 18 2023 at 14:52):

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

Last updated: Dec 23 2024 at 12:05 UTC