Drew Ridley (Apr 01 2025 at 20:33): Drew Ridley (Apr 01 2025 at 20:33):Hey all, I am currently working with the SurrealDB team to incorporate wasmtime into the runtime so users can write custom modules to perform heavy IO with WASI, as well as implement ratelimiting logic ontop of the query language.
While WIT might be a good candidate for this, the core 'Value' type Surreal uses is implemented in Rust.
pub struct Cast(pub Kind, pub Value);
Nested in the value type is the following. I was hoping the derive ComponentType would automatically assign names for these fields, but it does not. The documentation recommends against manually impling the trait but im not sure what option I have to proceed.
I would appreciate some guidance on how to handle situations like this, or if anyone has alternative ideas on how to pass SurrealQL values between guest and host code I would appreciate suggestions.
Alternatively, if there is a way to generate WIT bindings from rust source code, that could be used here and would probably provide a better overall experience for developers.
Pat Hickey (Apr 01 2025 at 21:13):We don't currently have a way to derive wit from Rust sources, only the opposite direction, via wit-bindgen for guests or wasmtime-wit-bindgen for hosts. Since you're talking about deriving ComponentType, Lift and Lower, thats all host side stuff. It might be possible to one day implement something that generates a wit from Rust sources that have manually-applied ComponentType derivations, but nobody is working on it that I know of. So, my suggestion for now is that you write your own wit for your interface, use wasmtime-wit-bindgen to generate types of it, and write From impls to translate between that and your Cast / Kind / Value types.
Drew Ridley (Apr 01 2025 at 21:15):Hi, thanks for getting back to me! This is extremely valuable for my work so I will be working on it and keep the group posted if I make any significant progress. Having a way to annotate host APIs with simple proc macros would be incredibly valuable for wasm adopton.
Pat Hickey (Apr 01 2025 at 21:18):in general its not dangerous to derive(ComponentType) manually, if thats something you want to do, and I don't see anything here that is really warning against it, just mentioning to consider bindgen instead https://docs.rs/wasmtime/latest/wasmtime/component/derive.ComponentType.html
Pat Hickey (Apr 01 2025 at 21:19):for pub struct Cast(pub Kind, pub Value); thats not a form of struct that the proc macro knows how to parse, though. if you were to rephrase it as pub struct Cast { pub kind: Kind, pub value: Value } then it ought to be able to derive(ComponentType)
Pat Hickey (Apr 01 2025 at 21:20):if you wanted to add support to the proc macro to parse pub struct Cast(pub #[component(name = "kind")] Kind, pub #[component(name = "value")] Value) thats a patch we'd accept
Pat Hickey (Apr 01 2025 at 21:22):maybe the attribute goes before the pub, idk, thats bikeshedding. id just look for prior art from serde on that. in general, I have never seen a tuple used like that for a struct, anytime theres more than one member its done with curlies and named fields, so idk whats idiomatic there
Pat Hickey (Apr 01 2025 at 21:23):essentially, the only danger you are in when you derive ComponentType is that the wit definition and your Rust host definition drift, and you will only catch that when linking to a component (at runtime), rather than at compile time if you use bindgen and From
Last updated: Apr 07 2025 at 08:04 UTC