bindings: Add native automatic re-export feature #59859
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This implements a native version of automatic re-export, similar to the macro from Reexport.jl. Doing this natively in the binding system has two key advantages: 1. It properly participates in binding resolution and world ages. If a new binding is Revise'd into a re-exported module, this will now propagate. 2. The re-exported bindings are allocated lazily, improving performance. An accessor for this functionality is provided as `@Base.Experimental.reexport`. However, the only supported argument to this macro is single `using` statement (unlike the Reexport.jl version, which has more syntax). It is my expectation that Reexport.jl will be updated to make use of the underlying funtionality here directly, the base version of the macro is mostly for testing. There are a few design warts here - in particular, we inherit the module name exporting behavior (JuliaLang/Reexport.jl#39). However, I think that would be best addressed by not exporting the module name itself from the modules but rather introducing the module name as an additional binding on `using` statements. However, this would be potentially breaking (even if the effect is unlikely to be seen in practice), so I'm not proposing it here. The Reexport.jl version of the macro can do whatever it needs to, including creating an explicit non-exported binding to suppress the automatic re-export for this if desired. Partially written by Claude Code.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This implements a native version of automatic re-export, similar to the macro from Reexport.jl. Doing this natively in the binding system has two key advantages:
It properly participates in binding resolution and world ages. If a new binding is Revise'd into a re-exported module, this will now propagate.
The re-exported bindings are allocated lazily, improving performance.
An accessor for this functionality is provided as
@Base.Experimental.reexport. However, the only supported argument to this macro is singleusingstatement (unlike the Reexport.jl version, which has more syntax). It is my expectation that Reexport.jl will be updated to make use of the underlying functionality here directly, the base version of the macro is mostly for testing.There are a few design warts here - in particular, we inherit the module name exporting behavior
(JuliaLang/Reexport.jl#39).
However, I think that would be best addressed by not exporting the module name itself from the modules but rather introducing the module name as an additional binding on
usingstatements.However, this would be potentially breaking (even if the effect is unlikely to be seen in practice), so I'm not proposing it here. The Reexport.jl version of the macro can do whatever it needs to, including creating an explicit non-exported binding to suppress the automatic re-export for this if desired.
Partially written by Claude Code.