alexcrichton commented on issue #6821:
One part of this is that it defines a hierarchy of types and then provides conversion of WIT and WITX-generated types into this hierarchy of types. That's reasonable for this crate since the set of types is quite small, but for something like
wasi-commonI'm not sure if that would work well (or larger proposals). In that sense it might make more sense to unconditionally generate WIT bindings (e.g. not a compile time feature) and always use the WIT types generated? That way there'd only be one conversion necessary which is WITX-to-WIT.Also one thing to consider is that this has
impl WasiNnTrait for WasiNnCtxwhich means that it's not going to be easily usable from embedders. Currently withbindgen!we're using something that looks likeimpl<T> WasiNnTrait for T where T: WasiNnViewso that way ifWasiNnCtxis embedded in a store somewhere theWasiNnViewdefines how to access it.Also as a final thing, it looks like the implementation bodies of WIT and WITX are duplicated? Would it be possible for one to delegate to the other?
abrown commented on issue #6821:
In that sense it might make more sense to unconditionally generate WIT bindings (e.g. not a compile time feature) and always use the WIT types generated
Yeah, I would prefer that. Is it fine if
wasmtime-wasi-nnenables thecomponent-modelfeature, though, forcing every user of this (e.g., the CLI) to do so too?
impl<T> WasiNnTrait for T where T: WasiNnViewI saw this over in
wasiorwasi-commonand didn't really "get" it. Let me look into it a bit more.Also as a final thing, it looks like the implementation bodies of WIT and WITX are duplicated? Would it be possible for one to delegate to the other?
They are duplicated in essence but not all the details are the same; e.g., anywhere we need a slice in
witx.rswe do the WiggleGuestSlicedance. I'll look into this a bit more...
abrown commented on issue #6821:
@alexcrichton: one more thought about your comments is that perhaps some of these improvements could be done as a separate PR. There is clearly more work that needs to be done here (e.g., replace all these temporary WIT files with their upstream versions, implement named models, etc.) so perhaps some of the refactorings you suggest could fit into some of those PRs.
Last updated: Dec 06 2025 at 06:05 UTC