extensions: Expose NAME
via reexport instead of const
#887
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Now that hand-written extension wrappers are exposed as
mod
ules instead ofstruct
s it is no longer needed to exposeNAME
as associatedconst
when a more-concisepub use
reexport will do.I'm still ambivalent what to do about
NAME
. Time and time again the question comes up why extensionX
isn'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 that
ash::extensions::
is only for those hand-written wrappers - andNAME
is 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 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 multipleNAME
s in different places.