Thanks for your work in putting this spec together, especially the yaml / json definitions!
I've started experimenting with switching my Swift binding generator from dawn.json to webgpu.json, but I've come across a few missing features.
There are no defaults defined for function arguments, which would be useful for languages that support optional or default parameters. I think this can be solved quite easily as the schema already supports a "default" property here.
However, I think the trickier problem might be that there is currently not a defined way to specify default values for certain types like arrays and strings. And for pointer types, there is a slight ambiguity in terms of nullability vs optionality.
A good example is setBindGroup(index, bindGroup, dynamicOffsets), which covers a few of these cases:
- index: non-nullable, non-optional
- bindGroup: nullable, non-optional
- dynamicOffsets: non-nullable, optional (defaults to empty array)
Here, bindGroup is a nullable pointer, but it is also non-optional, meaning the caller must always provide a value (which may be null). In webgpu.yml, this is marked as optional, meaning nullable, but it currently doesn't indicate that a value should always be provided. Again, this is probably irrelevant for the C API, but the distinction would be useful for other languages.
On the other hand, dynamicOffsets is a non-nullable array (although it is sort of nullable in C), but in supported languages the caller should be able to omit it.
I had a couple of ideas of how this could be expressed.
- Expand the "default" property to cover more cases. Having a default value would imply that the parameter can be omitted in supported languages. E.g.:
#example
- type: array<uint32>
default: []
- type: object.example
optional: true # i.e. nullable
default: "null"
- type: struct.example
pointer: immutable
optional: true # i.e. nullable
default: "null"
- type: struct.example
default: "default" / "zero"
- type: string_with_default_empty
default: ""
- type: nullable_float32
default: constant.nan
- Introduce separate "optional" and "nullable" properties. Optional would mean the parameter can be omitted in supported languages. The only benefit here really is that you don't always have to provide a default value as it can be inferred from the type.
- type: array<uint32>
optional: true # implies default is empty array
- type: object.example
nullable: true
optional: true # implies default is null
- type: struct.example
pointer: immutable
nullable: true
optional: true # implies default is null
- type: struct.example
optional: true # implies default is default initialized struct (unless default: zero is specified)
- type: string_with_default_empty
optional: true # implies default is ""
- type: nullable_float32
optional: true # implies default is constant.nan?
I'm open to any other suggestions. I appreciate this is beyond the scope of the C header, but IMHO it would be nice if webgpu.yml could be the source of truth for other language bindings, without needing other sidecar files.
Thanks for your work in putting this spec together, especially the yaml / json definitions!
I've started experimenting with switching my Swift binding generator from dawn.json to webgpu.json, but I've come across a few missing features.
There are no defaults defined for function arguments, which would be useful for languages that support optional or default parameters. I think this can be solved quite easily as the schema already supports a "default" property here.
However, I think the trickier problem might be that there is currently not a defined way to specify default values for certain types like arrays and strings. And for pointer types, there is a slight ambiguity in terms of nullability vs optionality.
A good example is
setBindGroup(index, bindGroup, dynamicOffsets), which covers a few of these cases:Here, bindGroup is a nullable pointer, but it is also non-optional, meaning the caller must always provide a value (which may be null). In webgpu.yml, this is marked as optional, meaning nullable, but it currently doesn't indicate that a value should always be provided. Again, this is probably irrelevant for the C API, but the distinction would be useful for other languages.
On the other hand, dynamicOffsets is a non-nullable array (although it is sort of nullable in C), but in supported languages the caller should be able to omit it.
I had a couple of ideas of how this could be expressed.
I'm open to any other suggestions. I appreciate this is beyond the scope of the C header, but IMHO it would be nice if webgpu.yml could be the source of truth for other language bindings, without needing other sidecar files.