Skip to content

Commit debbc22

Browse files
KristofferCDilumAluthgeMasonProtterfingolfinmbauman
authored and
KristofferC
committed
recommend explicit using Foo: Foo, ... in package code (was: "using considered harmful") (#42080)
I feel we are heading up against a "`using` crisis" where any new feature that is implemented by exporting a new name (either in Base or a package) becomes a breaking change. This is already happening (JuliaGPU/CUDA.jl#1097, JuliaWeb/HTTP.jl#745) and as projects get bigger and more names are exported, the likelihood of this rapidly increases. The flaw in `using Foo` is fundamental in that you cannot lexically see where a name comes from so when two packages export the same name, you are screwed. Any code that relies on `using Foo` and then using an exported name from `Foo` is vulnerable to another dependency exporting the same name. Therefore, I think we should start to strongly discourage the use of `using Foo` and only recommend `using Foo` for ephemeral work (e.g. REPL work). --------- Co-authored-by: Dilum Aluthge <[email protected]> Co-authored-by: Mason Protter <[email protected]> Co-authored-by: Max Horn <[email protected]> Co-authored-by: Matt Bauman <[email protected]> Co-authored-by: Alex Arslan <[email protected]> Co-authored-by: Ian Butterworth <[email protected]> Co-authored-by: Neven Sajko <[email protected]> (cherry picked from commit ee09ae7)
1 parent ced7df7 commit debbc22

File tree

2 files changed

+16
-1
lines changed

2 files changed

+16
-1
lines changed

base/docs/basedocs.jl

+8
Original file line numberDiff line numberDiff line change
@@ -37,6 +37,14 @@ kw"help", kw"Julia", kw"julia", kw""
3737
available for direct use. Names can also be used via dot syntax (e.g. `Foo.foo` to access
3838
the name `foo`), whether they are `export`ed or not.
3939
See the [manual section about modules](@ref modules) for details.
40+
41+
!!! note
42+
When two or more packages/modules export a name and that name does not refer to the
43+
same thing in each of the packages, and the packages are loaded via `using` without
44+
an explicit list of names, it is an error to reference that name without qualification.
45+
It is thus recommended that code intended to be forward-compatible with future versions
46+
of its dependencies and of Julia, e.g., code in released packages, list the names it
47+
uses from each loaded package, e.g., `using Foo: Foo, f` rather than `using Foo`.
4048
"""
4149
kw"using"
4250

doc/src/manual/modules.md

+8-1
Original file line numberDiff line numberDiff line change
@@ -112,7 +112,7 @@ and above. To maintain compatibility with Julia 1.10 and below, use the `@compat
112112

113113
### Standalone `using` and `import`
114114

115-
Possibly the most common way of loading a module is `using ModuleName`. This [loads](@ref
115+
For interactive use, the most common way of loading a module is `using ModuleName`. This [loads](@ref
116116
code-loading) the code associated with `ModuleName`, and brings
117117

118118
1. the module name
@@ -168,6 +168,13 @@ Importantly, the module name `NiceStuff` will *not* be in the namespace. If you
168168
julia> using .NiceStuff: nice, DOG, NiceStuff
169169
```
170170

171+
When two or more packages/modules export a name and that name does not refer to the
172+
same thing in each of the packages, and the packages are loaded via `using` without
173+
an explicit list of names, it is an error to reference that name without qualification.
174+
It is thus recommended that code intended to be forward-compatible with future versions
175+
of its dependencies and of Julia, e.g., code in released packages, list the names it
176+
uses from each loaded package, e.g., `using Foo: Foo, f` rather than `using Foo`.
177+
171178
Julia has two forms for seemingly the same thing because only `import ModuleName: f` allows adding methods to `f`
172179
*without a module path*.
173180
That is to say, the following example will give an error:

0 commit comments

Comments
 (0)