Jeet type inference transition for generic shader functions

Short answer

The question cannot be answered with confirmed facts about Jeet specifically, because no well-established, publicly documented shader-composition library by that name can be identified from available knowledge. It may be very new, renamed, internal, or described inaccurately. Rather than guess at its API, this answer separates what is solid ground (WGSL and WebGPU typing rules) from what must be verified against Jeet's own source or documentation.

What is confirmed: WGSL does not implicitly convert

WGSL is strongly and statically typed. With narrow exceptions defined by the spec (such as certain abstract numeric types concretizing at shader-creation time), it does not silently convert between scalar types like i32 and f32, or between vector widths. If a composed fragment feeds an f32 value into a slot expecting a vec4<f32>, the validator (Tint or naga, depending on the browser/runtime) will reject the module.

This has a direct consequence for the question: any implicit casting across mismatched instantiations must be inserted by the host tool during code generation, as explicit conversion expressions such as f32(x) or vec4<f32>(v, 0.0). If Jeet does not insert such expressions, mismatched generic instantiations will fail either at Jeet's composition phase or at WGSL validation. There is no third option where WGSL absorbs the mismatch.

Likely explanation (unverified for Jeet)

Tools in this design space typically pick one of two strategies, and the question's framing matches them:

• Strict matching at composition time: the graph linearizer unifies types across fragments and raises a compile-time error when a generic fragment is instantiated with incompatible scalar or vector types. This is the safer default and the more common choice in typed shader-composition systems.
• Cast injection during codegen: the tool inserts explicit WGSL conversion expressions at fragment boundaries. This is more permissive but can hide precision or width surprises.

Which one Jeet's stable API uses is unknown here and should not be assumed.

Impact on the binding layout

Resource binding in WebGPU is governed by the declared types and @group/@binding attributes in the final WGSL, plus the matching bind group layout on the host side. Type inference between value-producing fragments does not, by itself, alter the binding layout. It only affects bindings if the inferred type changes a resource declaration — for example, a generic uniform or storage buffer whose element type is inferred from usage and resolves to f32 in one instantiation and vec4<f32> in another. In that case the buffer sizes and alignment differ, and the host-side bind group layout must match whichever was emitted, or validation fails at pipeline creation.

How to verify the actual behavior

1. Confirm the project's real name and repository — the name may be a misspelling or codename — and read its codegen/inference source rather than release notes.
2. Compose one generic fragment instantiated twice with deliberately mismatched types (e.g., f32 vs vec3<f32>) and inspect the emitted WGSL: look for inserted conversion calls versus a composition-time error.
3. Run the emitted WGSL through Tint or naga standalone. If validation rejects the mismatch, the tool is not injecting casts.
4. Diff the @group/@binding declarations between instantiations to see whether inferred resource types change the required bind group layout.

The one diagnostic detail that would change this recommendation is the exact error (or generated WGSL snippet) Jeet produces for a mismatched instantiation — that output alone distinguishes strict matching from cast injection.