You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
0 commit comments