LGTM as well, seems like a good future-proofing strategy.

Does omitting layout mean the same as having passed layout: 'auto'?

No, it doesn't. And that's intentional.

As it turns out, using the auto layout is relatively limiting and probably not the pattern that most developers want to reach for instinctively. It can be a nice shortcut if you know that you won't need the same layout anywhere else, but we wanted that to be an intentional decision on the part of the developer and not the default.

So now you always have to specify a layout, and can explicitly choose auto if that's what you need. The hope is that doing things this way helps nudge developers towards better practices.

[EDIT] I'm an idiot, and didn't realize this was talking about the shader module hint and not the pipeline layout. Sorry.

In this context omitting the layout simply means not providing a hint, which means that any backend that might have tried to pre-emptively optimize with that information can't. If you explicitly specify auto then the backend may be able to to optimize for the case where you use this module with a pipeline using the auto layout as well. Similarly if you gave an explicit layout in the hint the backend may be able to to optimize for the case where you use this module with a pipeline using the same layout. (Although please note: No backends that I'm aware of perform any optimizations with layout hints to date.)

Given that they're just hints, omitting any aspect of that dictionary simply means "No hint provided."

Thanks - the reason I am asking is that when marshalling over to wasm, handwritten JS code could specify any type of hint object of form:

• null (i.e. no hint object specified at all)
• { },
• { layout: null },
• { layout: undefined },
• { layout: 'auto' }
  so I am trying to figure out what type of polymorphic expressiveness here is needed for wasm side programs to be able to pass. The four first ones are quite reasonably the same thing, but then wondering if wasm code should be able to say { layout: 'auto'} as well, or if that case could be handled statically as one of the above four cases.

I filed webgpu-native/webgpu-headers#166 .