I added a draft PR to illustrate the idea, let me know if this fits the goals of Screen 13 or not.

The logic is basically inspired by similar changes and a proc-macro I contributed to Vulkano recently, relevant code:
https://github.com/vulkano-rs/vulkano/blob/master/vulkano/src/pipeline/graphics/vertex_input/vertex.rs
https://github.com/vulkano-rs/vulkano/blob/master/vulkano/src/pipeline/graphics/vertex_input/definition.rs

However I simplified the implementation and reduced the amount of types involved, I do think this would fit Screen 13 as I believe this is a nice escape hatch, when more control of the vertex input state is required.

Take the chosen type names with a grain of salt, the draft was thrown together in a couple of minutes, name proposals appreciated.

This change definitely fits the goals of the crate; I want to deliver something that allows easy use of the common Vulkan use-cases and also allows full access to all the options when needed. This is one area which falls short currently, because users cannot specify some types at all, for instance *_USCALED or *_PACK32 in addition to what you mentioned.

This area shares a similar design issue to sampler selection; I'm not really happy with the ..._sampler_nnr-type naming scheme either:

• It puts configuration that may change (supported device/format properties) directly in the shader code
• It feels very clunky naming things (and then using those names!)
• It doesn't allow the other options like borderColor or unnormalizedCoordinates

This naming system came from Kajiya, and although it works I don't want to extend it to this bad API:

layout(location = 0) in vec3 position_ibind0_r16g16b16_unorm;

For both issues, there are super common values that most people will use and learning some Screen-13-specific language is not what they have in mind, so a system where sane defaults are used and then the GraphicsPipelineInfo type allows specialization which looks exactly like the native Vulkan types, but without vk::Bool32 and other icky things, is the best idea I have.

I'll add comments and suggest code changes on #56 - although it will probably over the next week. Thank you again for this!

Perfect, that gives me some time to polish up the PR and think some more about it. As it was honestly a very rough first draft. I just wanted to get the idea out of my head.

I agree with you that samplers suffer from similar limitations right now.