alexcrichton commented on issue #4219:
I'll also note that this is suspiciously light on tests. I honestly completely ran out of steam once I encountered the lifetime issue described above. I can try to write some more smoke tests here and there next week.
alexcrichton commented on issue #4219:
It's also worth pointing out that the limitation of Rust here is basically the same one that forces us to today box the futures returned by host functions.
github-actions[bot] commented on issue #4219:
Subscribe to Label Action
cc @peterhuene
<details>
This issue or pull request has been labeled: "wasmtime:api"Thus the following users have been cc'd because of the following labels:
- peterhuene: wasmtime:api
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
alexcrichton commented on issue #4219:
I have raised a question on the Rust internals forum about possibilities related to trait bound design here. While we can definitely achieve something that I didn't think was possible (closing over the arguments in the return value) it requires many refactorings to the trait bounds and may also affect all callers to do something fancy as well. That's very quickly moving into the reaml of "while maybe possible almost certainly not plausible" and I'm not sure how well it would work out here.
Otherwise my best hope is that the trait bounds involved here for host functions is a relatively isolated part of the implementation of the component model. In some sense there's no need to hold up everything else related to the component model to figure this out. Ideally we can somehow in the future figure out how to improve the "return a string" story without needing massive changes to everything else in the implementation.
Last updated: Nov 22 2024 at 17:03 UTC