Stream: wasmtime

Topic: Is anyone using `WasmStr` or `WasmList<T>` as a guest return

view this post on Zulip Alex Crichton (Jan 29 2026 at 17:54):

Currently in Wasmtime's API we have Func::call{,_async}. When calling these functions we additionally require embedders to call Func::post_return{,_async}. The intention here was to enable hosts to type guest return values with WasmStr and WasmList<T> to enable zero-copy usage of wasm return values.

In practice, however, bindings generation never uses WasmStr nor WasmList. Additionally they're cumbersome and not super well documented. So my theory at this current time is no one is using this capability despite perhaps wanting such a capability in the future.

The reason I ask is that call_concurrent, added with component-model-async, already acts quite differently. The call_concurrent function automatically calls post-return for async reasons. This split has been a source of bugs and headaches and in talking with @Joel Dice we're concluding that the best route forward would be to (a) remove the embedder-level API of Func::post_return and (b) in the future add a method of calling a function where the results are communicated via a closure. This closure would be able to use WasmStr/WasmList and would work with call_concurrent.

I wanted to ask, though, is anyone using this functionality? If so we can plan more on keeping it in the meantime and/or game out what this closure-based API would look like.

view this post on Zulip Alex Crichton (Feb 03 2026 at 19:24):

This change is landing in https://github.com/bytecodealliance/wasmtime/pull/12498

deprecate `[Typed]Func::post_return[_async]` and make them no-ops by dicej · Pull Request #12498 · bytecodealliance/wasmtime
With the advent of the Component Model concurrency ABI and it's task.return intrinsic, post-return functions have been informally deprecated and are expected to be removed for WASI 1.0 and the ...

Last updated: Feb 24 2026 at 04:36 UTC