Make `extern mod xxx` optional

[liigo]

@brson suggested me open a new issue on this idea, "it seems worth exploring", he said. He don't want this to get buried in #11745 too. See comments in #11787.

The Problem

To use a crate in rust, at least two lines are required currently:

extern mod xxx;
use xxx::a::b;

In a large project, we need to use many crates, particularly after extra's dissolution (#11787). The more crates we need, the more lines extern mod xxx need to write, which is a pain:

extern mod crate1; // do we really need to write this?
extern mod crate2; 
extern mod crate3;
extern mod crate4;
......
use crate1::*; // compiler can infers "extern mod crate1" from here
use crate2::*;
use crate3::*;
use crate4::*;
......

The Solution

Since we must write lines such as use xxx::a::b, the compiler should always knows I'm using the crate xxx. So the extern mod xxx is redundant, it should be optional, unless compiler got ambiguity in non-common situations.

[emberian]

I never want to be linked to crates by using an import. Additionally, this is trivially broken in the face of glob reexports. I feel like the ever-so-slight cost in extra lines is an extremely small price for ease of recognition of shadowing, as well as explicitly knowing what I'm linking to.

[sinistersnare]

Is is possible that we can have syntax such as:

extern mod {crate1, crate2, crate3, crate4};

as opposed to:

extern mod crate1; // do we really need to write this?
extern mod crate2; 
extern mod crate3;
extern mod crate4;

This way it keeps the explicitness of every crate in use, while removing all of the supposed extra extern mod's created by the pull request that started this.

[emberian]

yeah that'd be nice actually.

On Sun, Jan 26, 2014 at 12:39 AM, Davis Silverman
notifications@github.comwrote:

Is is possible that we can have syntax such as:

extern mod {crate1, crate2, crate3, crate4};

as opposed to:

extern mod crate1; // do we really need to write this?
extern mod crate2;
extern mod crate3;
extern mod crate4;

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11811#issuecomment-33309880
.

[pcwalton]

I don't like this. use is for namespace management; extern mod is for linking. The information that use needs is different from the information that extern mod (which really should be extern crate) needs. This is inherent to having a two-level namespace system. I strongly suspect that conflating the two concepts will just lead to more confusion down the road.

However, I'd be totally fine with extern mod {foo, bar, baz};

[adrientetar]

As others said, extern mod is not redundant and it has a different use than use. Adding stacked declarations would solve the problem through without risking conflicts or auto-linking.

[gdonval]

Then why not make that crystal clear? link crate {foo, bar}; or link extern crate {foo, bar}; seems clearer in its purpose than the current extern mod which seems superflous (to me at least) because one doesn't not what it is used for.

After all, in python, a simple import is all it takes. Why bother with declaring twice something that can be declared only once?

By making it clear that this is required in the linking process, this decision makes much more sense. People coming from C wouldn't complain that much if they knew this is similar to their beloved "-l" linker argument.

By the way, I don't know if that really makes sense, but I've seen a lot of in-crate link-args wouldn't it be more convenient to use extern "C" mod {foo, bar}; or link "C" crate {foo, bar}; to link C libs to the current crate instead of #[link-args="-lfoo,-lbar"]?

[thestinger]

A mod statement includes a file or a block of code as a module. The extern mod statement includes an external library as a module. An extern mod statement is not used to link to C ABI libraries. Both mod and extern mod bring a module into the tree under the name given in the statement.

The term "crate" is cute Rust jargon, but it's not going to help in understanding the language. If we're worried about clarity then we should drop the usage of "crate" completely and call them libraries.

[thestinger]

I opened #11819 to cover the issue of multiple inclusions per statement. This issue should stay on the topic of removing mod and extern mod or be closed.

[huonw]

By the way, I don't know if that really makes sense, but I've seen a lot of in-crate link-args wouldn't it be more convenient to use extern "C" mod {foo, bar}; or link "C" crate {foo, bar}; to link C libs to the current crate instead of #[link-args="-lfoo,-lbar"]?

It's now #[link(name="foo")] extern { ... }, and there's #2124 open about adding a feature to read C headers. It could possibly look something like #[header(name="foo.h", link_name="bar")] extern mod baz;.

[thestinger]

@huonw: I think it would probably link to the module name by default, as it does for Rust crates. The header is just the missing data to make it into a proper extern mod.

[huonw]

That would certainly work too.

[liigo]

After making extern mod xxx optional, you can still always write it explicitly. But even it is absence, the compiler can infers exactly the correct extern crates to be linked in, no one crate less, no one crate more. Even you write these by hands, you can't do any more than compiler. What's the reason you oppose making it optional? Examples?

[thestinger]

How will the compiler distinguish between a module called foo and an external module called foo? Will it priortize local modules over external ones?

Anyway, I don't understand why extern mod foo would be optional but mod foo wouldn't be. You need to present a coherent plan rather than just stating it should be optional without thinking about how to do it.

[liigo]

The compiler can not distinguish between two modules both named foo, no matter whether extern mod x is optional or not. @thetinger