Update README (Was: Detect ambiguous glob bindings lazily)

[glaebhoerl]

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.)

[nikomatsakis]

On Sun, Sep 14, 2014 at 12:32:03PM -0700, Gábor Lehel wrote:

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.

The newer prototype indeed allows this. The README is somewhat out of
date, actually. I should revise it. I have not because I am still in
the process of prototyping macro expansion and working out how that is
supposed to integrate.

[glaebhoerl]

Cool! I've changed the title then. :)

I am still in the process of prototyping macro expansion and working out how that is supposed to integrate.

(I had some very preliminary/high-level thoughts about this, but haven't had the opportunity yet to study the subject in greater detail - it seems less urgent than other things.)