Rethinking the idea of the Parsed type.

[iwoplaza]

The current way to get the type of value that a schema describes is via the Parsed<T> generic type, meaning:

import { Parsed } from 'typegpu';
import * as d from 'typegpu/data';

const rgb = d.vec3f; // alias

const Gradient = d.struct({
  from: rgb,
  to: rgb,
});

type Gradient = Parsed<typeof Gradient>; // => { from: vec3f, to: vec3f }

This made sense from the perspective of typed-binary, as the resulting type is what you got from parsing a sequence of bytes. In the context of TypeGPU, this parallel is a bit less applicable. I propose we change this API to reflect its current purpose to ValueOf<T> instead.

type Gradient = tgpu.ValueOf<typeof Gradient>; // => { from: vec3f, to: vec3f }

[mhawryluk]

agreed! let's do it ^^

[reczkok]

I'm a bit late to the party here. While I don't disagree with the name being less applicable, I don't think 'ValueOf' is a better alternative. I would argue that what we are doing is closer to "parsing" the WGSL schemas to get the TS counterparts, than it is to getting a value from them since we are in type land.

[iwoplaza]

Okay, lets try and workshop this. From an I/O standpoint, Parsed makes a lot of sense, since that is what the schema is parsed into. But as we add more and more functionality apart from just I/O, this would make less and less sense in those contexts.

For example, from the perspective of the GPU (in TGSL shaders), the Parsed values are not actually being parsed, they just are. Zod uses z.infer as their "parsing" type function, maybe we can just use that as well? It could be a parallel for TS users already familiar with Zod.

import tgpu from 'typegpu';
import * as d from 'typegpu/data';

const rgb = d.vec3f; // alias

const Gradient = d.struct({
  from: rgb,
  to: rgb,
});

type Gradient = tgpu.infer<typeof Gradient>; // => { from: vec3f, to: vec3f }

[iwoplaza]

Let's do a quick poll, should we do:

• ❤️ // tgpu.Infer since its a type, or
• 🚀 // tgpu.infer to mirror the z.infer Zod type?