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 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 `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.
Co-authored-by: Keno Fischer <[email protected]>
0 commit comments