Hey all,
I have been trying for a while to figure out how to implement a component in Rust that uses a resource; I have attached the relevant files.
field_db.wit
lib.rs
Cargo.toml
expanded_51
I have tried a number of different things, but it seems that each thing I try, causes the compiler to direct me towards something different, in some cases contradictory; for instance, if I define theget_iterator function to return FieldIterator, it complains that it should be Self::FieldIterator. If I then define it to be Self::FieldIterator, it complains that it expects it to be FieldIterator.
Eventually, I used cargo expand so I could look at the generated code, but understanding that code is a bit beyond my current level of skill in Rust. It seems like FieldIterator is already defined by the generated code, and that it acts on an implementation of GuestFieldIterator; should I be implementing that trait instead of trying to create FieldIterator?
If anyone could offer assistance, or even better, an example of how to do something like this, it would be very helpful for me; I have been looking for examples but without much luck.
Also, looking at issues in the wit-bindgen repository to try to find information or examples has led me to wonder how far along support for resources is; am I trying to use this too soon?
You can’t use the generated binding type itself as the Guest resource implementation.
type FieldIterator = crate::bindings::exports::...::FieldIterator will not work because that FieldIterator is just the generated interface, not a concrete implementation.
For WIT resources, you need to:
crate::bindings::exports::...::FieldIterator trait for that structtype FieldIterator in your Guest implFor example:
struct FieldIteratorImpl {
// internal state here
}
impl crate::bindings::exports::...::FieldIterator for FieldIteratorImpl {
// implement resource methods here
}
struct Component;
impl Guest for Component {
type FieldIterator = FieldIteratorImpl;
// ...
}
export!(Component);
In short:
resource types are handles managed by the component, not aliases to the generated binding types. The generated trait defines the interface; you must provide the backing implementation yourself.
Thank you, this does clarify a few things.
I am trying to follow this example, though, and hitting a snag when trying to implement crate::...FieldIterator. The compiler states that it is a struct, not a trait, so it cannot be implemented.
The only traits in the generated bindings appear to be:
Guest, GuestFieldIterator, and WasmResource; that being the case, am I right in thinking that the iterator trait I need to implement is GuestFieldIterator?
@godotdot
crate::...FieldIterator. The compiler states that it is a struct, not a trait, so it cannot be implemented.
Sorry! I missed the example code.
it needs to fix using GuestFieldIterator.
impl GuestFieldIterator for FieldIteratorImpl { ... }
@ktz_alias No problem, thank you for confirming the trait I should be implementing.
Though, having spent a few more hours looking at the generated code and trying to get this to work, I am completely confused at this point.
The generated code implements FieldIterator as a concrete type.
It implements GuestFieldIterator as a trait.
FieldIterator uses GuestFieldIterator.
The Guest trait uses a FieldIterator type, but that type is required to implement the GuestFieldIterator type.
So if I do something like:
struct GuestFieldIteratorStruct;
impl GuestFieldIterator for GuestFieldIteratorStruct {
unsafe fn _resource_new(val: *mut u8) -> u32 {
12345
}
}
struct GuestStruct;
impl Guest for GuestStruct {
type FieldIterator = GuestFieldIteratorStruct;
fn get_iterator() -> FieldIterator {
}
}
The compiler complains that FieldIterator is not in scope for the Guest impl.
It then suggests either:
1 - using Self::FieldIterator, i.e. implement fn get_iterator -> Self::FieldIterator.
2 - importing the concrete FieldIterator from the generated code.
If I do 1, then it complains that it expected FieldIterator, and got GuestFieldIteratorStruct,
and suggests that I use FieldIterator.
If I do 2, then it complains that it needs me to return a FieldIterator; fair enough, that makes perfect sense.
So then I need to call pub fn new<T: GuestFieldIterator>(val: T) -> Self and return the result.
Unfortunately, it seems to me that takes a GuestFieldIterator, which does not implement new,
so I can't create a new GuestFieldIterator as an argument to the concrete FieldIterator::new().
I'm sure this is me being a complete newb to Rust and getting in over my head,
but I am really at a loss right now.
The code is quite old and the instructions seem to be partially outdated, but I posted resource examples in many languages at https://github.com/cpetig/resource-demo - perhaps this can give you some inspiration.
Even if it's old, it may still be useful to me.
If nothing else, it's already made me rethink my decision of having a get_iterator function rather than just using constructor; not sure why I did that at this point, but I should have considered that when I ran into issues due to GuestFieldIterator not having a new().
Thank you for the examples. If I have some questions about them later, do you mind if I ask?
@godotdot
The compiler complains that
FieldIteratoris not in scope for theGuestimpl.
It then suggests either:
1 - usingSelf::FieldIterator, i.e. implementfn get_iterator -> Self::FieldIterator.
2 - importing the concreteFieldIteratorfrom the generated code.
Associated types are not brought into scope like generic type parameters.
They always belong to a specific trait implementation, so Rust requires you
to qualify them explicitly.
Self::FieldIterator means “the FieldIterator associated type of this impl Guest for GuestStruct”.
Ah, I see now. Thank you for the explanation!
godotdot said:
Thank you for the examples. If I have some questions about them later, do you mind if I ask?
I don't mind, feel free to ask.
Last updated: Feb 24 2026 at 04:36 UTC