Generated bindings for `VkLayerSettingEXT` are confusing/inappropriate

[tomaka]

The VkLayerSettingEXT struct has a values field that is a pointer to some data, and a ty field indicating the type of data.

ty can be one of: boolean, 32 or 64 bits signed or unsigned integer, 32 or 64 bits floating point, or string.

According to this example, when ty is for example a boolean (booleans in Vulkan are always 32 bits), then values must point to 4 bytes of memory containing the boolean value.

However, the values setter generated by ash accepts a &[u8], and automatically does valueCount = values.len().
So for example if you want to pass an integer, you might be tempted to do .values(&u32::to_ne_bytes(some_value)), but that would set valueCount to 4, which is wrong, as it's supposed to be 1.
If I'm not mistaken, it's not possible to actually use this API without relying on transmute-based dark magic.

[Ralith]

A handwritten special case here would be useful. Otherwise, you can avoid error-prone unsafety by using bytemuck or similar.

[Ralith]

We'll definitely need the special case to avoid having to manually set valueCount correctly, though.

[tomaka]

I suppose that we can replace values with multiple functions values_string, values_bool, etc. that each accept a different type for the slice (&[&CStr], &[bool], etc.) and also automatically set ty to the correct value.

[Ralith]

Alternatively, a trait LayerSettingValue { fn as_bytes(&self) -> &[u8]; fn len(&self) -> usize; } could make this DWIM nicely.