Personally I have a hard time seeing this as idiomatic, or preferable to the approach taken in this commit,
Mostly out of curiosity, is there anything in particular that strikes you as unidiomatic?
We are making certain trade-offs, of course; the existing code allocates the new descriptor info, fully initialises it, and leaves it immutable afterwards. There are advantages to that, and I think it works well enough for the relatively few parameters we have in the existing code. It leaves little room for optional/default parameters though; callers like vkd3d_shader_scan_constant_buffer_declaration() and vkd3d_shader_scan_resource_declaration() that don't need flags still need to explicitly specify them as "0". 06/10 essentially preserves that, but uses struct vkd3d_shader_descriptor_info1 to pass the parameters. The other extreme would be to have vkd3d_shader_scan_add_descriptor() only allocate the storage, and making the callers responsible for initialising everything. You could imagine a caller like vkd3d_shader_scan_constant_buffer_declaration() then doing something like this:
```c info = vkd3d_shader_scan_add_descriptor(context); vkd3d_shader_descriptor_info_init_cbv(info, cb, cb->size); ```
with vkd3d_shader_descriptor_info_init_cbv() doing something like this:
```c vkd3d_shader_descriptor_info_init(info, VKD3D_SHADER_DESCRIPTOR_TYPE_CBV, &cb->src.reg, &cb->range, VKD3D_SHADER_RESOURCE_BUFFER, VKD3D_SHADER_RESOURCE_DATA_UINT); info->buffer_size = vec4_count * 16; ```
The proposed alternative doesn't go quite that far, but it shifts things a little bit more in that direction.
but I can see the advantage, so if it's a weak preference I'll go ahead and change it accordingly.
I think it would be slightly nicer, yes.