RFC: Remove glob-import functionality completely

[Aatch]

Glob import statements are a frequent cause of confusion and bugs in Rust code. They currently exist behind a feature gate, so there is already some pressure against them.

I suggest removing them completely. The only thing I can think of that would be a significant issue about removing the glob functionality would be how it affects the prelude. However, we could just special case prelude functionality.

The advantage of this is that would make the resolution algorithm much simpler, since the glob import functionality adds significant complexity.

cc @pcwalton

[Aatch]

I couldn't find an issue for this already.

[huonw]

#3352 is a rather confusing bug with rustc that seems to be triggered by globs. (As evidence against them.)

[metajack]

We don't really use globs in Servo, except in the auto-generated code bindings. It would be pretty hard for us to remove them I think.

Not so much voting for globs here as hoping someone else has a good idea for how we can live without them. In general I dislike them, but they seem to have some limited use.

[seanmonstar]

I otherwise love Rust's importing syntax. Any symbol used in the module is defined in the module or I can find it by looking at the uses. If I were writing a large Rust application, just as a Java application, I would r- any PR that contains use foo::bar::*. Making this not even an option removes the argument that may come up when I r- :)

[nikomatsakis]

I think glob imports have their place. For example, in the borrow
checker, there is a shallow tree of submodules that all make use of
data types defined in borrowck/mod.rs. It seems rather tedious and
silly to require manual importing of all these names, vs just writing
use rustc::middle::borrowck::*. I know that there are complications
in the resolution algorithm, though, and I would be more amenable to
an argument based on fundamental challenges there.

[rust-highfive]

This issue has been moved to the RFCs repo: rust-lang/rfcs#305