wasmtime
wasmtime copied to clipboard
bytecodealliance
`bindgen!` creates separate types for imports and exports of an interface
Originally discussed on Zulip here: https://bytecodealliance.zulipchat.com/#narrow/stream/217126-wasmtime/topic/Sharing.20generated.20code.20between.20same.20interface.20import.2Fexport
It would sometimes be convenient to share the generated types between imports and exports of an interface, e.g. if one component calls the host though a given interface and then the host forwards the call to some other component in an entirely separate instance using the same interface.
This is currently not possible, and so conversion between the structurally-identical but separate types must be done manually. If there is a good reason why the imported and exported WIT types should be generated as separate Rust types, perhaps conversions between them should be generated for when you know that's what you want to do?
EDIT: Another use case this would help is extending generated types with extra behavior and sharing that through a crate.
I think one way to possibly solve this would be to create some sort of has for a type which models the structure and then deduplicate based on this hash. That would chiefly have to incorporate differences in resources and additionally details like borrowing specific to Rust. Afterwards deduplication based on that shouldn't be too too hard.
Small tangent: it sounds like this could also be used for the dynamic representations to avoid the need for deep equivalence tests on each call. Does that sound right?
Ah, sorry, I forgot about this.
There's a decent chance I've misunderstood something, but my current understanding is that when you call a component function from a host dynamically (i.e. using wasmtime::component::Func), it first performs a deep structural type-check.
If all types that are capable of structural equivalence had a content hash associated with them, could that be used in an additional fast path in check to save from doing the deep structural check with every call? Maybe this is only relevant when taking values from one store and passing them to a different store (otherwise it looks like there is an existing fast path??) but that is a use case that is important to me.
All that said, I'm not actually champing at the bit for higher performance or anything; I'm currently only tinkering on hobby stuff, and only mentioned this at all because I'd been looking at the relevant code recently and wondered if it would be low-hanging fruit in a future world where component types already had a convenient hash hanging around.