Reevaluate `extern mod` as syntax for importing crates.

[brson]

It's not that well loved. It doesn't have anything to do with other uses of extern, and lexically it must be written in a different position than other extern things.

[brson]

Nominating.

[catamorphism]

+1. I always feel embarrassed when I have to explain this to someone.

[Kimundi]

The mod part is also confusing, as it doesn't declare a new module, but rather create an import of an external binaries crate root.

For example, this creates two interchangeable paths to the same module tree:

extern mod extra;
mod foo {
    extern mod extra;
}

While this creates two distinct modules:

mod extra;
mod foo {
    mod extra;
}

[catamorphism]

1.0, backcompat

[brson]

"crate" seems to be the consensus.

[brson]

@huonw can mentor

[huonw]

If someone does want some mentorship, feel free to contact me by commenting here, on IRC (nick: dbaupp) or via email (in my profile).

[flaper87]

I'll work on this one

[thestinger]

I like extern mod, as it works the same way as a mod statement but includes an external module rather than an internal one via source code. I think the term crate is very much insider Rust jargon and won't be as helpful for a newcomer. I don't think this is why people have trouble with Rust's module system.

[eddyb]

Do we really want to add another keyword with just one use case?
And so I'm not completely negative, I see two other ways we can say extern crate without crate being a keyword:

// A procedural macro can expand to an ExternCrate AST node.
extern_crate! extra;
// Similar here, though attributes may not map as well to the AST.
#[extern_crate(extra)];
// These should still work (do we allow visibility on extern mod?):
#[cfg(foo="bar")]
pub extern_crate! foobar;

[sfackler]

Would crate really need to be an extra keyword? Is there any reason that the compiler can't special case a crate ident coming after an extern keyword?