Why does Rust encourage explicit import statements?

Question

I see a lot of Rust code where use expressions look like this:

 use std::io::net::ip::{SocketAddr, Ipv4Addr}; 

As I understand it, this limits the use statement to only importing SocketAddr and Ipv4Addr .

From the point of view of languages ​​such as Java or C #, this seems strange since with such languages ​​the import statement always imports all public types.

I figured that with this statement you can have the same thing in Rust.

 use std::io::net::ip::*; 

The only reason I could see the explicit naming would be to avoid conflicts when two different imports contain public APIs with the same name. However, this could be worked out using aliases, so I wonder if there is another advantage to the more rigorous approach of “importing only what is needed”?

Answer 1

Rust is inspired by Python, which has a similar principle: import is all explicit, and although glob support ( use x::* in Rust, from x import * in Python) is supported, they are usually not recommended.

This philosophy does have some practical implications; calling the attribute method, for example, can only be done if the attribute is in scope, and therefore invoking the attribute method when names clash in imported attributes is quite difficult (this will be improved in the future using the Uniform Function Call Syntax, where you can call Trait::function(self) , not just self.function() ).

Basically, this is what Zen of Python expresses well: "Explicit is better than implicit." When a vast area of ​​things is in scope, it can be difficult to understand what happened from where deep knowledge of the structure of the module and / or snap becomes very important; if it is all explicit, the toolkit is largely unnecessary, and working with files manually in a simple text editor is quite feasible. Of course, the toolkit will still be able to help, but this is not so necessary.

That's why Rust adopted the concept of explicit Python imports.

Answer 2

• A mailing list sheet asking why importing globes is not preferred

which writes Huon

Some aspects of them greatly complicate the name resolution algorithm (as I understand it), and, in any case, they have different disadvantages for the actual code, for example. Python equivalent is not approved: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing

Perhaps they are not so bad in a compiled and statically typed language? I do not know; In any case, I personally find the code without importing glob easier to read, because I can decide which function is called very easily, while importing the globe takes a lot of effort.

• The problem of removing glob imports

where nikomatsakis writes

I think that the import of globes has its place. For example, in a loan controller, there is a small tree of submodules that all use the data types defined in borrowck/mod.rs It looks rather tedious and stupid to require manual import of all these names, but just write use rustc::middle::borrowck::* . I know that there are complications in the resolution algorithm, though, and I would be a more amenable argument based on the fundamental problems there.

He then moved to RFC 305 , which was rejected by steveklabnik without commenting on whether they are good:

Globe import is now stable, so I'm going to close this.