You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Reevaluate extern mod as syntax for importing crates. #9880
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.
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.
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;
For the record, extern mod does not currently work the same as mod:
Like mod, it adds new definitions to be usable from inside the crate.
But like use, multiple extern mod statements that refer to the same crate refer to the same definitions, and the items in them can be used interchangeably.
The patch that introduced the crate keyword landed already. The step left is creating a new snapshot for stage0 and replace all usages of extern mod with extern crate
Activity
brson commentedon Oct 15, 2013
Nominating.
catamorphism commentedon Oct 15, 2013
+1. I always feel embarrassed when I have to explain this to someone.
Kimundi commentedon Oct 16, 2013
The
modpart 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:
While this creates two distinct modules:
catamorphism commentedon Oct 17, 2013
1.0, backcompat
brson commentedon Oct 31, 2013
"crate" seems to be the consensus.
brson commentedon Jan 27, 2014
@huonw can mentor
huonw commentedon Jan 27, 2014
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 commentedon Jan 27, 2014
I'll work on this one
thestinger commentedon Jan 29, 2014
I like
extern mod, as it works the same way as amodstatement but includes an external module rather than an internal one via source code. I think the termcrateis 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 commentedon Jan 29, 2014
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 cratewithoutcratebeing a keyword:sfackler commentedon Jan 29, 2014
Would
cratereally need to be an extra keyword? Is there any reason that the compiler can't special case acrateident coming after anexternkeyword?flaper87 commentedon Jan 30, 2014
@sfackler not 100% but I think that in the case of
extern modit is already treated as an ident.Kimundi commentedon Jan 30, 2014
For the record,
extern moddoes not currently work the same asmod:mod, it adds new definitions to be usable from inside the crate.use, multipleextern modstatements that refer to the same crate refer to the same definitions, and the items in them can be used interchangeably.Example:
32 remaining items
flaper87 commentedon Feb 14, 2014
The patch that introduced the
cratekeyword landed already. The step left is creating a new snapshot for stage0 and replace all usages ofextern modwithextern crate