Closed YishiMichael closed 8 months ago
Thanks a lot for spotting this issue! I will adjust that asap.
One approach I have observed to correctly detect tags in extension names is to parse the name attribute in the extension xml node, try to fetch the second upper-case segment (representing the tag), and parse also the depends attribute in the require xml node and fetch the second upper-case segment (the latter supersedes the former).
As I dive deeper, I find such convension does not generally apply to all extension names - there are too many cases that do not follow the pattern. As a quick-and-easy fix, I now would suggest to take enum members of VendorId
and DriverId
as special cases that cannot have any trailing tag.
You're right, there are too many exceptions that don't follow the general pattern. Another option here would be to just leave it as it is. After all, it's in there for a while, and changing that might require changes in some users code. And I don't know, if some day there might materialize some enum value that are supposed to have a trailing tag, so special case handling for those two enums does not sound like a good approach.
Agree. So I'll close this issue for now.
When looking into some enumerant interfaces provided by Vulkan-Hpp I noticed some naming inconsistency:
I know that the enumerant names are automatically generated by first detecting possible tag names at behind. But sometimes the last segment of a name happens to collide with one of possible tags when that segment does not really represent a tag, resulting in the inconsistency above.
One approach I have observed to correctly detect tags in extension names is to parse the
name
attribute in theextension
xml node, try to fetch the second upper-case segment (representing the tag), and parse also thedepends
attribute in therequire
xml node and fetch the second upper-case segment (the latter supersedes the former).