Should more functions take extensible structs?

[kainino0x]

Struct chains provide extensibility to methods that take an extensible struct as an argument, like CreateBuffer. But there are a number of functions which don't. In JavaScript, all functions are extensible because we can add optional arguments to the end, but not in C.

Functions that could make sense to take extensible structs:

• WriteBuffer
• Submit
• OnSubmittedWorkDone
• GetCompilationInfo
• device Destroy
• EnumerateFeatures
• GetMappedRange/GetConstMappedRange
• MapAsync/Unmap
• PushErrorScope/PopErrorScope
• SetUncapturedErrorCallback
• ProcessEvents
• ~GetPreferredFormat (JS API is likely to extend this)~ Being removed in #290
• GetCurrentTexture (we said this was OK in #203)
• Present

The following take extensible structs that are shared with other functions so may not be always cleanly extensible:

• WriteTexture (also I'm not sure WGPUImageCopyTexture should be extensible?)

These aren't extensible, but I don't think they need it:

• encoder commands
• Reference/Release
• FreeMembers
• buffer/texture/queryset Destroy
• SetLabel
• getters like GetWidth, GetBindGroupLayout, GetQueue
• Unconfigure

(I think that's the complete list)

[kainino0x]

• Device destroy?
  • KN: Could want an “emulate backend device loss”, could be a new function
• encoder commands?
  • CF: could definitely be extended
  • KN: was thinking if that happens we just make a version 2 of the function
  • CF: oh, only really need it in encoder creation
  • KN: those are already extensible
• …
• KN: off the top of my head, I think the most likely to get extended are: \ Submit, ProcessEvents?, GetPreferredFormat, GetCurrentTexture?, Present

[Kangz]

MapAsync / Unmap for multi-queue as well.

[kainino0x]

meeting: discussed a little, but didn't conclude exactly which entry points we wanted to change. We want to add extensibility to at least some of them, so we can start with the easiest ones like GetPreferredFormat, at least.

[kainino0x]

Note per #115 any function that takes an extensible struct needs to be able to return an error code if you pass something invalid in the struct chain.

[kainino0x]

Likewise, should we have some form of both in and out extensibility for present? For example to request present timings.

Originally posted by @Kangz in https://github.com/webgpu-native/webgpu-headers/issues/261#issuecomment-2315100082

[kainino0x]

Sep 12 meeting:

• "should we have some form of both in and out extensibility for present? For example to request present timings."
• Probably yes, and probably single pointer chain (not separate in chain and out chain; double check that this is consistent with other decisions)

[kainino0x]

• double check that this is consistent with other decisions

it's not; see https://github.com/webgpu-native/webgpu-headers/issues/261#issuecomment-1910889507

I'll keep thinking about this.