Description
The README says:
Cannot have two glob imports that would import the same name, or a glob import and a glob-re-export
(Until recently it was clear that this is also what the code implements; I haven't stared at the new code long enough to be able to tell if it's still the case.)
In terms of:
Globs fully supported, behavior is "what you expect" (well, what I expect, at least).
however, I think it would be preferable if conflicts between names imported by globs were allowed, and an error were only raised when one attempted to actually use that name.
As an example, I would expect this to be accepted:
mod a { pub fn foo() { } pub fn bar() { } }
mod b { pub fn foo() { } pub fn baz() { } }
mod c {
use a::*;
use b::*;
fn quux() {
bar();
}
}
where two functions called foo are imported, but as I don't attempt to use either one, the compiler doesn't complain. If I were to write:
fn quux() {
foo();
}
then the compiler would yell at me that foo is ambiguous between a::foo and b::foo.
In practical terms, with eager ambiguity checking of glob imports, two glob imports would conflict if the two modules have even a single name in common, and this possibility seems far from improbable; and reliably avoiding it would require unreasonable amounts of coordination between module authors to avoid choosing the same names (this is the kind of concern a module system is supposed to free us from!). In short, eager checking would significantly impair the usefulness of glob imports.
(Eager checking would still be preferable for glob re-exports, because a module exporting multiple items with the same name (i.e. exporting an ambiguity error) seems absurd, and should be caught at that point rather than downstream.)