Benjamin Saunders

I think we should prefer not to complicate our public API except when it is specifically known to solve a real problem someone's having.

> The reason it's so big is because I decided to refactor the ExampleBase so it matches https://vulkan-tutorial.com/ I haven't reviewed any changes yet, but this immediately gives me pause....

I find I reference `ash::Device` often, so the current concise name is nice. No harm in improving the docs, though.

I think a PR modifying the generator to omit the lifetime specifier where unused would be welcome.

This can be used in a `const` context, which should not copy at all. In the cases where it does, LLVM will likely optimize it away. By contrast `read_spirv` always...

> Then it will do the stack allocation in a const context, which is probably also not what you want. If you don't believe that will optimize it, you can...

> I think this variant of the macro will work in a const context It doesn't, which is exactly why you needed to replace `const` with `let` in the example....

`Pin::new_unchecked` is unsafe because the soundness of other safe interfaces depends upon it, which is not the case here. All Vulkan API calls are unsafe regardless, due the very wide...

We've discussed merging with erupt in the past, and trying to assemble the best of both worlds. A detailed writeup of where the libs currently differ, and proposals for which...

Sounds good to me, thanks!