Ergonomics when having code and spec side by side

[zopsicle]

When working with Vulkan I often want to look up something in the spec. Prior to using Ash I did this by selecting the relevant identifier in my source code, then copying it and pasting it into the search field of the spec. The other way around, copying identifiers and structures from the spec into my source code is also something I often do as it is very convenient with long names and large structures.

However, Ash renames all the identifiers to Rust naming conventions, making this a hassle. I have to convert to and from snake case, remove or add the vk prefixes, and so on.

I wonder if anyone else has run into this and come up with a convenient workflow.

[MarijnS95]

This should only be an issue for enum variants, all types and functions should (and if not it should be fixed) have a link to the documentation in their doc-comment. If using an editor like VSCode with rust-analyzer these links show up on hover and are clickable.

I agree that it might be a little bit harder to transpose code from C to Rust or the reverse (and for looking up or copying from documentation), but it's been a decision made long ago that I agree with. It gets rid of unnecessary redundancy in names (e.g. moving vk to be a module and stripping enum types out of enum-variant/associated-constant names as they're properly scoped/qualified in Rust) as well as sticking to Rust's naming conventions to make all Vulkan code look uniform within a codebase.

Vulkan-Hpp has gone the same route, fwiw.