Stream: git-wasmtime

Topic: wasmtime / issue #10706 Support custom generic bounds in ...

view this post on Zulip Wasmtime GitHub notifications bot (May 02 2025 at 08:28):

simonask opened issue #10706:

Feature

Currently, #[derive(ComponentType)] etc. requires that all generic struct parameters directly and unconditionally implement ComponentType. It would be useful to be able to specify custom bounds for the trait impl, similar to #[serde(bounds = "...")].

Benefit

I'm the author of glamour, a strongly typed vector math library. My vector types have a Unit generic param, and all the fields of the vector are defined in terms of an associated type Unit::Scalar, which is always a primitive. So for Vector4<T>, the T only appears in the struct as T::Scalar (which always implements Lower + Lift), but T itself does not implement Lower + Lift.

The current derive macros mean that only the "untyped" units (plain scalar types, such as Vector4<f32>) can implement ComponentType etc., which is unfortunate - it would be nice to be able to leverage this kind of type safety in automatically generated WIT bindings.

More generally, this would provide an escape hatch for some of the problems with "imperfect derive".

Implementation

I would propose extending the derive macro to support a #[component(bounds = ...)] attribute at the container level for structs and enums, replacing the implicit T: ComponentType bound (same for Lower and Lift derives).

Alternatives

  1. The derive macro can be amended to emit an impl that is bounded on the specific field types of the struct, i.e., collect all field types and add bounds for each type that appears as a field. This may be less attractive because it reveals internal things about the type, potentially making it more brittle (semver hazard).
  2. Currently it is not feasible/possible to manually implement ComponentType/Lower/Lift. That API could be stabilized, allowing users to handle the problem themselves.

view this post on Zulip Wasmtime GitHub notifications bot (May 02 2025 at 14:56):

alexcrichton added the wasmtime:api label to Issue #10706.

view this post on Zulip Wasmtime GitHub notifications bot (May 02 2025 at 14:57):

alexcrichton commented on issue #10706:

Sounds reasonable to me to implement! This has good precedence as you point out throughout the proc-macro ecosystem in Rust, so should be fine to mostly copy/model the implementation on a preexisting crate.

view this post on Zulip Wasmtime GitHub notifications bot (May 08 2025 at 16:29):

alexcrichton added the wasm-proposal:component-model label to Issue #10706.

Last updated: Dec 06 2025 at 07:03 UTC