Benjamin Saunders

> So I guess they would have to do something like SomeHandle::from_raw().unwrap_or(SomeHandle::invalid()), but then passing that to a destroy_ function would not be good. Note that `invalid` is not exported....

vk.xml also (in theory) has enough information to let us do this same trick for "flags" fields, which sometimes must be nonzero. I think I'll see how that works out...

Optional bitflags seem to work okay, and are mostly ergonomic. The generated API for the flags types themselves is unfortunately higher-friction; many operations must now return `Option`, and some had...

My understanding is the intention there is to replace `uint64_t` with opaque struct pointers on platforms where doing so does not affect the ABI, purely so that C++ users get...

It seems like the vulkan-docs repo isn't very fast-moving. Perhaps we could work off a fork for now, if we want this in for the next ash release?

Following discussion with @kvark in IRC, I've removed the bitflags component of this change; only handles are now affected. Our conclusion was that the practical benefit of encoding this information...

There are months-old reasonable pull requests still open with little feedback, so it may be quite some time. It's a shame to cut a release with known breaking changes pending,...

It looks like that change (flagging `pNext` as optional in most cases) is still a long way from the pervasive cleanup envisioned here. IIRC the specific changes in this PR...

I've just been passing `&[vk::ImageView::null(); N]`.

Thanks, that would be awesome!