bytecodealliance
[rust-macro] generate! should allow defering handling exports to dependent crates
See discussion here: https://bytecodealliance.zulipchat.com/#narrow/stream/327223-wit-bindgen/topic/external.20export.20implementations/near/387677837
I also want this feature. It kind of used to exist with the old export macro approach that was replaced when resource type support was added. You used to be able to have one library crate that called generate! and exported the "export" macro to any dependent crates who could then bind the exports of the world. When resource types were added the API changed to force the invoker of generate! to specify what interfaces it was exporting and implement them right then and there (at least that's my understanding).
As @alexcrichton mentioned wastime's bindgen! macro lets you do something like this already with more sophisticated macro parameters. Perhaps this approach could be applied here too.
Yeah this is one I'd love to see solved but I don't see a path forward myself unfortunately. I'm hoping others can have better ideas though!
The crux of the problem is that previously it was possible to generated exported types ahead-of-time and then use that from the exports macro later. This breaks down with resources, however, because as the implementor of the exports you likely want to define resources in addition to exports. This ends up meaning we can't define the types until the implementor is in-scope which means generate! is required by end users and can't be done in libraries.
One possible fix is to split generation of imports and exports, e.g. Wasmtime's interfaces option. One other possible fix is to generate an exports macro which handles all exported types, not just the exported implementation. Unsure how much these would fix the underlying issues though.
Other possible solutions might entail redoing how exported resources are represented, and I haven't gone too far down that path myself yet.
Theres a similar issue in the cargo-component repo, but pasting my comment here since I am using wit-bindgen:
Adding in my use case here. I have a need to make a library that wraps some wasi:http functionality for use in multiple (Rust) components. Specifically I need to implement a replacement http-connector for an SDK I would like to use that is not by default not functional in wasm/wasi. At the moment I can't see any way of doing that beyond making my library a kind of no-op component. It would be ideal if I could somehow import the wasi:http functions into my library without having to jump through the build hoops of having a stubbed component for it.
