Vulkan vs Rust

Vulkan. You know what it is. But why isn't it out yet?

Oh, what do you know, it's because Rust programmers are complaining it's difficult to interface with their FFI because of Rust's lack of unions, so these SJWs are bitching about it to try to change Vulkan's data structures to be less optimized in order to favour Rust.

Rust is fucking garbage and these rustcucks are fucking up what could be a good API.

https://www.khronos.org/message_boards/showthread.php/9649-Official-Vulkan-Feedback-API-for-High-efficiency-Graphics-and-Compute-on-GPUs?p=38243&viewfull=1#post38243

The issue here is that C bitfields have implementation-defined (and underspecified) layout

Doesn't this also holds true for structs in general? The standard only guarantees that the pointer to a struct will point to the first object of it, not where the rest of the objects will be.

typedef struct _GR_FORMAT

This is bad too, because underscore and a uppercase is reserved by the standard.

GR_UINT32

I hope these stupid types will disappear. You want a unsigned 32 bit integer? Use uint_least32_t, not this yet another typedef to int.
Plus, if I am not mistaken, the C standard only defines the behaviour when the bitfield type is of int, signed int, unsigned int and _Bool.

GR_ENUM

What the fuck?

In any case, I hope this silliness of Mantle does not exist in Vulcan.

>>2
struct layout for plain integer types is at usually defined by an OS specific ABI standard; bitfields don't always get that level of standardization. The System V ABI is notably silent on bitfields (most implementations follow gcc, but it's not wise to rely on that). structs with plain integer types are well defined, however.

GR_UINT32 is likely there to allow support for systems that don't provide stdint.h, or need to use a different type for whatever reason (can't think of any reason for the latter though).