Roadmap

[kainino0x]

• [x] Split ffi bindings into files for: common, xcb, xlib, windows, wayland, etc. Right now we have only xcb.
• [ ] Write translation of triangle.cpp from SaschaWillems/Vulkan. Fix things along the way. (SLOC stats on triangle demo.)
  • [ ] Also take a look at LunarG/VulkanSamples.
• [ ] Finish up the bindings. This means: xlib, win32, wayland, mir, vk_*.h? ...
• [ ] Finish moving things which are extension-defined (*KHR) into the appropriate modules.
• [ ] What do we do about SPIR-V? Do we need bindings for that too in order to get anywhere?
• [ ] Look into whether we can generate bindings in the current style using the spec XML.

[kainino0x]

Thoughts on how to make a nice relatively-rustic FFI interface:

• Would like extensions to be able to look like they add variants to core "enums" (e.g. additional VkResult definitions) without over-involved namespacing.
  • (Currently using this.) The only way I've thought of to do this so far is with associated constants. An impl in each extension will inject the variants into the "enum" namespace.
  • Unfortunately, associated constants are still unstable. Given that this API is intended to be primarily exposed to a safer-bindings layer above it (not used by application developers), perhaps the improved ergonomics is not worth it.
  • The biggest problem I've thought of with this is that enum-style debug prints won't work and will be annoying to implement. I don't think it's possible to implement them in an extensible way, either.
  • Right now I'm using struct(i32), but I'm not clear whether struct(u32) is technically more correct.
  • Enums: can't inject variants. Also, there is the problem of match exhaustiveness. That basically rules them out, if we want the modularity.
  • Modules (or no namespacing): Here, adding variants means polluting a global namespace or something weird and unergonomic to the user.
  • A lot of the Vulkan enums are flags types. I would use bitflags for this, but they wouldn't be extensible. The setup I have now (using associated constants, at 646b0ca) will work if I just implement &, |, etc. for each type. Again, no nice debug printing.
  • (Currently using this.) The FlagBit and Flags need to be defined separately, because many places in the API seem to make the distinction. & and | can be implemented for every permutation of FooFlag and FooFlags. The FooFlag is just a struct(u32) with associated constants (similar to above); FooFlags is also a struct(u32), but must be constructed from FooFlag values.