On Thu Jul 13 14:21:07 2023 +0000, Zebediah Figura wrote:
I'm not terribly convinced this is something that needs changing.
Personally I don't particularly care about identifier length at all, slightly preferring more descriptive names even. I don't want to push this to an annoying degree, but I do care. Long names take longer to type, and they increase the likelihood that lines will need to wrap, which I think makes them categorically less readable. Autocomplete can help, especially if your editor supports partial autocomplete, but it can't really help if your identifiers share common prefixes (Vulkan "vk" vs. "vkd3d_" vs. "vkd3d_shader_"). The key sequence 'd3d' is also kind of nasty to qwerty keyboards [which is unavoidable to a degree in this line of work, but still.]
I'm not all that convinced about distinguishing between external and
internal API based on naming either—essentially, something is internal until we decide to export it—but I'll grant that there are fewer constraints on names for purely internal API. The reason I like this distinction is that it helps reading comprehension. It makes it easier to understand the scope of the code you're working with and how it fits together [which is a bit of a vague statement but I think still true]. It makes it clear what you can and can't refactor and why a function call or whatever is arranged the way it is. Currently if I want that I have to intrinsically remember what is and isn't API, which is hard and I still have to look up identifiers sometimes, even after working on this code base for quite a while. [E.g. enum vkd3d_shader_type, enum vkd3d_shader_register_precision, enum vkd3d_data_type, enum vkd3d_shader_input_sysval_semantic, struct vkd3d_shader_version, struct vkd3d_shader_desc, look like public API but aren't.] I'd also like to point out that the naming of this IR layer doesn't really make it clear that it is an IR layer, that's something I'd like to change.
If we do end up doing something like this it would be very helpful to
hold it until the SM 6 work is mostly upstream. Yeah, that's fair. I usually err on the side of doing refactors first, to lessen the amount of code they thrash, but this is definitely creating more work for other people at this rate.
For the record, I happen to agree with Zeb here, though not with a very strong opinion. Meaning that I also believe that shortening that identifier can save me a little amount of work, but not more than a little one.