How do Compat extension structs work on output?

[kainino0x]

For Compat extension structs we have this special behavior:

Special: implementations that don't support Compatibility Mode must ignore any chained structs with @ref WGPUSType values in this block, instead of erroring. This block must only be used for Compat additions that can be ignored without affecting the semantics of a non-erroring program.

However for output structs I'm not sure how this should work. (Pretty sure there is just one case of this, the Compat extension to the WGPULimits struct - #472.)

1. Should the struct remain unpopulated (as this would imply)?
2. Should we never put compat structs in that SType block, keep them in core and require them to be implemented?

I think 2 makes the most sense to me.

[eliemichel]

Option 1. would mean that the Compat extension is populated if and only if the adapter is Compat, so users that want to check this output should not forget to check that the adapter is Compat? For the case of limits it feels ok because the init macro would set the limits of the Compat extension to the undefined sentinel value, so in the case of a non-Compat adapter the result is just "limit is undefined", which makes sense w/o checking that the adapter is Compat.

That being said, if it is only 1 case, it might be better to go for Option 2. so that we don't add an extra rule just for 1 case.

[Kangz]

Could we alternatively add compat atomically to webgpu.h at some point (when it lands and sticks in the WebGPU spec) and then request that all implementations of webgpu.h support all of compat at a time? After the initial addition there should be no more additional compat additions no?

[Kangz]

Ah it would break API stability after webgpu.h v1 is stable so that's a bad idea nvm.

[kainino0x]

+1 to both. @cwfitzgerald, WDYT?