I am tempted to say we might want to allow for specifying the tag and version here too. Or rather take a `struct vkd3d_shader_dxbc_desc` as input and ignore size and checksum (or even allow for flags to use them even if they're invalid).
Not that I have any real usage in mind, of course, so that should probably be ignored. I happen to like symmetry, and I don't see reason for having the parsing interface allowing for the hypothesis that a format change might in theory happen, and the serializing interface not doing the same.
I could be convinced, but I had this taking a vkd3d_shader_dxbc_desc structure originally, and it was mostly just an inconvenience when implementing D3DGetBlobPart() and D3DStripShader() on top of vkd3d_shader_serialize_dxbc(). It also implies adding validation for the tag and version. How about I change it if you can convince Zeb?
Heh. My position wrt issues like this, as a consumer of many APIs of different styles, is that the easiest APIs to work with are the ones with relatively simple functions, and also that rerolling an API, even rerolling it several times, doesn't actually make things any harder to work with. (Nor to implement, I think). Especially when all you're rerolling is the function signature itself. So if it were up to me, I'd just remove the tag and version from both sides.
But that said, I'm not going to bikeshed this very hard, since it's a pretty minor concern. I just wanted to make sure that some alternatives were thought of (or, more saliently, discussed in a public place; I do quite trust Henri to think of design questions like that.)