AttachmentDescription.samples should not be a flags type

[silversquirl]

According to the Vulkan spec, VkAttachmentDescription.samples is of an enum type that happens to contain the bit flags used in a flag type.
vulkan-zig incorrectly changes this enum type (VkSampleCountFlagBits) to the corresponding flags type (VkSampleCountFlags) in the generated AttachmentDescription struct.

[Snektron]

Yes, the intended way to go about that is to pass a flags structure with a single field set. There are a few other occasions where the raw FlagBits variant is used in the Vulkan spec.

The problem is that in C, the _BIT variants automatically translate into the Flags structure because both are just an integer really. In Zig we don't really have that, and this was the most straight forward way to implement it. Of course i could generate two different types, a struct and an enum, but then it would be relatively annoying to convert between the two as you'd basically be required to use a bitCast. Furthermore, working with the flags type would require a bunch of functions, like

var my_queue_flags = vk.QueueFlags.init(.{.graphics_bit, .compute_bit});
my_queue_flags.contains(vk.QueueFlags.init(.{.graphics_bit, .compute_bit}));

I guess these extra calls could be mitigated by adding extra code that checks the actual passed in type and then allowing contains(.{.graphics_bit}) and contains(.compute_bit) or whatever, but that might get complicated quickly. In the end i just preferred writing .{.graphics_bit = true, .compute_bit = true} here instead.

[silversquirl]

Is it common to need to turn a flag bit (enum) value into a flags (bitfield) value? I've not seen anywhere it'd be terribly useful, but maybe I'm wrong.

It's not a huge deal either way, but it feels odd to use a flags bitfield struct for a value that can only have a single bit set.

[Snektron]

Is it common to need to turn a flag bit (enum) value into a flags (bitfield) value? I've not seen anywhere it'd be terribly useful, but maybe I'm wrong.

Im not sure about that. I do know that the Flags variants are much more often used than FlagBit variants in general, though. I'm not such a fan of a toMask() function either way though. I'd rather go all the way and do QueueFlags.init(.{.graphics_bit, .compute_bit}).

It's not a huge deal either way, but it feels odd to use a flags bitfield struct for a value that can only have a single bit set.

I agree that its not terribly useful like this, also from a "self-documenting" perspective.