Skip to content

Commit 85aecff

Browse files
KristofferCKristofferC
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 7442535 commit 85aecff

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

doc/src/manual/modules.md

+8-1
Original file line numberDiff line numberDiff line change
@@ -105,7 +105,7 @@ modules. We will see how to manage name clashes below.
105105

106106
### Standalone `using` and `import`
107107

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

111111
1. the module name
@@ -161,6 +161,13 @@ Importantly, the module name `NiceStuff` will *not* be in the namespace. If you
161161
julia> using .NiceStuff: nice, DOG, NiceStuff
162162
```
163163

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

0 commit comments

Comments
 (0)