Now that hand-written extension wrappers are exposed as modules instead of structs it is no longer needed to expose NAME as associated const when a more-concise pub use reexport will do.
I'm still ambivalent what to do about NAME. Time and time again the question comes up why extension X isn't available in ash::extensions::, and we have to explain that this is only for hand-writen extensions for which no wrapepr has been written yet, or is more often than not a command-less extension that does not need a wrapper.
Veterans will know that ash::extensions:: is only for those hand-written wrappers - and NAME is re-exposed from ash::vk:: there purely for convenience - but anyone else seems to expect all extensions to be available there. Not to mention that my extension lists in various apps look funky when mixed with ash::extensions::XXX::name() and ash::vk::XXXFn::name() (old 0.37 syntax).
This was also brought up recently in different form (citation needed): why not combine the autogenerated ExtensionFn with the hand-written wrapper (effectively have the handwritten wrapper extend it)? Regardless of if/how/when we implement that, such an approach could also eliminate having multiple NAMEs in different places.
Now that hand-written extension wrappers are exposed as
modules instead ofstructs it is no longer needed to exposeNAMEas associatedconstwhen a more-concisepub usereexport will do.I'm still ambivalent what to do about
NAME. Time and time again the question comes up why extensionXisn't available inash::extensions::, and we have to explain that this is only for hand-writen extensions for which no wrapepr has been written yet, or is more often than not a command-less extension that does not need a wrapper. Veterans will know thatash::extensions::is only for those hand-written wrappers - andNAMEis re-exposed fromash::vk::there purely for convenience - but anyone else seems to expect all extensions to be available there. Not to mention that my extension lists in various apps look funky when mixed withash::extensions::XXX::name()andash::vk::XXXFn::name()(old 0.37 syntax). This was also brought up recently in different form (citation needed): why not combine the autogeneratedExtensionFnwith the hand-written wrapper (effectively have the handwritten wrapper extend it)? Regardless of if/how/when we implement that, such an approach could also eliminate having multipleNAMEs in different places.