-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge function pointer table struct with high level wrapper struct #876
Comments
I'm weakly in favor of this, since very few users will care about the One case that might call for a raw function table struct is storing wrapped functions in the implementation of a layer, in which storing the handle is (usually?) going to be redundant to the passed-in handle -- but even there, having access to the ergonomic wrappers is more valuable than saving a few bytes. |
#894 unifies the module hierarchies. It does not unify the structs, but since they're now clearly documented and immediately adjacent, confusion from those should be at least lessened. Once it's merged, making the function pointer tables themselves private, if we want that, would be a trivial addition. |
I hope the function pointer tables, and everything else in the |
@Rua the proposed PR that will close this issue does exactly that: it moves the original types around to sit inside the same module, but otherwise keeps their original definition the same. You are still able to use the function pointer loaders without the |
-- Using VK_KHR_swapchain as an example:
I think it's pretty confusing to have both
ash::extensions::khr::Swapchain
andash::vk::KhrSwapchainFn
. Is there a good justification for why the wrapper functions shouldn't be directly defined on the struct that also holds the function pointers?I originally alluded to this in this comment: #734 (comment).
The Device handle would be a bit awkwardly grouped with the function pointers, but overall it results in an easier to grok API, especially after the changes in #734.
The text was updated successfully, but these errors were encountered: