overly aggressive ambiguity errors

[paulp]

% cat a.rs
use std::io::error::*;
use std::thread::*;

fn main() { }

% rustc a.rs
a.rs:2:5: 2:20 error: a type named `Result` has already been imported in this module [E0251]
a.rs:2 use std::thread::*;
           ^~~~~~~~~~~~~~~

Issuing an ambiguity error about a name which is never used does more than create needless busywork and break namespace encapsulation. It means you can never add anything to a module without breaking an unknown and unknowable amount of source code in the wild when you happen to choose the same name as did some other crate.

[paulp]

Rust is almost pathologically aggressive here. A name which I never use and where all imports leads to the same type (one a straight re-export of the other) is still sufficient cause to fail the compile, e.g.

use std::collections::*;
use std::collections::hash_map::HashMap;

This also illustrates that named imports aren't given priority over wildcard imports.

I initially had high hopes for pub use because in principle it would allow for the construction of a sane convenient namespace. The current error semantics mean that it's unusable for that purpose because it can't be composed with any other imports without creating conflicts - even when the "conflicting" imports are identical to the ones which it is exporting.

[alexcrichton]

This behavior is currently intended design and the possible breakage is known (and has mitigation strategies).

It's possible to relax these requirements and allow conflicting imports if the conflict isn't actually used, but changes like this would require an RFC (and belong in the rust-lang/rfcs repo). Thanks for the report regardless, though!

[pythonesque]

From the RFC you linked:

However, wildcard imports are now feature gated, and name conflicts in general can be resolved by using the renaming feature of extern crate and use, so in the current non-gated state of the language there is no need for this shadowing behavior.

Since wildcard imports are no longer feature gated, I don't think it's accurate to say that the current behavior is intended.

[aturon]

Just to clarify, this is not the long-term intended design. Name resolution is currently over-conservative. I think most people want, and expect, precisely the semantics @paulp is laying out here. (In fact, the mitigation strategies @alexcrichton points to are exactly the changes @paulp is asking for.)

However, as @alexcrichton mentions, we don't currently have a fully fleshed-out and approved design here in the form of an RFC, which is our process for undergoing such changes.

cc @nikomatsakis

[glaebhoerl]

cc rust-lang/rfcs#553