Item 22: Avoid wildcard imports
use statement pulls in a named item from another crate or module, and makes that name available for use in the
local module's code without qualification. A wildcard import (or glob import) of the form
use somecrate::module::* says that every public symbol from that module should be added to the local namespace.
As described in Item 20, an external crate may add new items to its API as part of a minor version upgrade; this is considered a backwards compatible change.
The combination of these two observations means that you should avoid wildcard imports from crates that you don't control. If you ignore this advice, you run the risk that a (backwards compatible) upgrade to your dependencies will cause your code to stop compiling, because the new symbol in the dependency happens to clash with a name that your code is already using. If your code is a crate that others depend on, then those users in turn can also have their builds broken by a dependency upgrade.
If there's some reason why you can't follow this advice, then you should mitigate the risk: pin dependencies that you wildcard import to a precise version, so that minor version upgrades of the dependency aren't automatically allowed.
Finally, if you do control the source of the wildcard import, then the concerns given above disappear. For example, it's
common for a
test module to do
import super::*;. It's also possible for crates that use modules primarily as a way
of dividing up code to have:
mod thing; pub use thing::*;