-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
import/using search order? #2375
Comments
After thinking about this some more, I realized that the current behavior is not a bug. But I do think that a change is motivated not to let the implicit |
This is really all about the search order for |
There are some cases where code has relied on the current behavior, e.g. |
…ax search from Main (the top level). addresses #2375 this is quite disruptive, but I think I prefer it. after all, most of the imports in Base are of internal modules, so they should be marked as such.
should this be closed now? |
Ok, I believe I have the final design for this on the |
merged into master. |
In the example below are three (top level) modules,
ModA
,Meta
, andModB
.ModB
attempts to use the other two.The trouble is that
ModB
has an implicitusing Base
, which shadows the top levelMeta
module:Running this in the repl gives me
This behavior caused me the trouble in toivoh/Debug.jl#35:
Debug.jl
has a sub-moduleDebug.Meta
. WhenBase.Meta
was added, it shadowedDebug.Meta
for the otherDebug
sub-modules. In general, it seems to me that the current behavior with implicitusing Base
risks to break existing code each time an export is added toBase
.My suggestion is to change name lookup within a module according to:
using Base
in any moduleBase
as a fallback.An alternative would be to change the interpretation of
using
to provide a fallback only if an identifier is not found in any other way.The text was updated successfully, but these errors were encountered: