Apps are able to override any override value in the shader, that's what they're for, so they can be set from the application side. I'm not sure what you mean, or do you mean you want the app to change the default, and to somehow also override the default?

Unused and unset overrides are only needed if they're statically used by the program, if they aren't used they should be fine.

Apps are able to override any override value in the shader, that's what they're for, so they can be set from the application side. I'm not sure what you mean, or do you mean you want the app to change the default, and to somehow also override the default?

Yeah, I wrote that unclearly. I'm distinguishing between host code (e.g. in JavaScript), app code in WGSL, and package code in WGSL. Let's call it root code rather than app code. And of course, the assumption is that there's some way for WGSL root and package code to bring in code from other packages, like an import statement.

So if root WGSL code imports package WGSL containing override fooBinding = 7;, the root WGSL should be empowered to change the 7 to a 9 without relying on host code. That's for encapsulation, root WGSL controls the host api, not some package. So after the app WGSL says import pkg/fooBinding;, something else new like allowing fooBinding = 9; at the root level will be called for. That's what I meant by changing the semantic of override. It's solvable, and probably we need to come up with something anyway for overrides in packages irrespective of whether overrides are allowed for binding/group indices.

But what do you think of the argument that binding/group indices are best set in host code? I think that's the case but I'm not sure. That road might lead to something like @publicBinding (with @binding and @group still available but not recommended).

You don't need publicBinding to set them in JS code, we'd just need to make them able to take an override and then you could override from the JS.

Yes, override for bindings can make libraries possible. My question is whether that's the style we should encourage for WGSL libraries or even WGSL applications going forward.

If we encourage WGSL library programmers to use @binding, we need to explain to them that they should never give a constant parameter to @binding, always create an override, but never give a default value for the override. Basically binding numbers should never be written in library WGSL even though @binding syntax makes it tempting.

I'm not arguing that publicBinding is the best alternative, but I hope it illustrates that alternatives are feasible that don't tempt users into putting binding numbers in WGSL.

And wouldn't it anyway be better to encourage future WGSL application writers (not just library writers) to control any bindings from the WebGPU application code (e.g. TypeScript)? If that were possible, I argue that would be the best practice to encourage.

(Also if we do encourage override for @binding, there's the issue of enabling application root WGSL to change library WGSL overrides. That's a separable issue that I've only sketched above, but it's moot for @binding if we discourage @binding anyway.)

Library authors can do as they wish, if they want to use a constant value, they can. If they wanted to use an override, they can do that as well. How they write their WGSL is up to them.

I don't understand the overriding part, WGSL doesn't have imports, so that isn't an issue for WGSL, and even if it did, you can just leave the override and have the user set it from JS.

I don't understand the overriding part, WGSL doesn't have imports,

Right, to enable libraries today, we'll extend WGSL with a community transpiler that support imports. Hopefully WGSL libraries will become widely supported either through built in features or std tooling.

Library authors can do as they wish, if they want to use a constant value, they can. If they wanted to use an override, they can do that as well. How they write their WGSL is up to them.

And if the question is what are the fewest changes WGSL needs to make for libraries, nothing is urgent here. WGSL and WebGPU is an amazing achievement and we can use it as a transpilation target without any change.

But you all have been on such a long road to get to 1.0! Isn't it a little tempting to start thinking about improved ergonomics for future versions of WGSL? It's in that context that I'm raising the issue. Maybe too soon? Apologies if so.

Apologies for being a little cheeky with that last comment. What I meant to suggest is that there are three frames to address a problem like this one about making WGSL friendlier for libraries.

1. Since libraries aren't much use w/o a way to package and import WGSL, do nothing.
2. Look for minimal changes to WGSL so that library code can be mostly legal WGSL, even if some things (e.g. a module system) are handled by community tools for now.
3. As WGSL looks toward adding more ergonomics post 1.0, look for ways to evolve WGSL to a more library friendly language.

I'm arguing for the third and wider approach. Let's look for the most ergonomic way to enable libraries, even if it might be a bigger change and slower to land. We can polyfill with community tooling in the interim.

I argue that enabling a library ecosystem is important enough that it justifies considering non-minimal changes. So I'm trying to tempt you into the wider frame of possibilities. Who better to help think about the problem? After all, no one has thought more about the ergonomics of web shader languages than you.

Placing this in Milestone 2, with other issues for WGSL for programming-in-the large.