Module system cleanup

[Kimundi]

Remove a few unnecessary restrictions and inconsistencies in the module system, namely:

• Lift the hard ordering restriction between extern crate, use and other items.
• Allow pub extern crate as opposed to only private ones.
• Allow extern crate in blocks/functions, and not just in modules.
• Optionally keep the order restriction as convention with a warn-per-default lint

Rendered

[aturon]

I would love to remove the various restrictions (especially the ordering restriction, which often requires uses before definitions) as proposed in this RFC. I've always considered the ordering restriction a wart.

I'm ambivalent about the lint. In general, we probably will want lint(s) corresponding to our coding guidelines, but these are not completely nailed down now. And removing the ordering restriction may allow new guidelines to emerge.

[sfackler]

👍 I also think this will ease the way for macros to expand to both items and view items, which should allow us to avoid some of the sketchiness present in e.g. #[deriving(Decodable)].

[vks]

I'm ambivalent about the lint. In general, we probably will want lint(s) corresponding to our coding guidelines, but these are not completely nailed down now. And removing the ordering restriction may allow new guidelines to emerge.

The lint could be made opt-in for now.

[blaenk]

This is great. I think there's no better reason to do this than the fact that—as you showed—these restrictions can already be worked around. We might as well clean this up.

[cessen]

As a relatively new user of Rust, I can confirm that mod statements having to go after use statements was very confusing, and still feels backwards to me when I write it. Intuitively, it feels like I ought to tell Rust about a module before referencing it.

I realize that isn't how it actually works, but from a human perspective that's how it feels like it would work, to the extent that it didn't even occur to me that the ordering could have been wrong. Even after getting the error message from the compiler, I still tried about gazillion other things before finally changing their ordering on a lark (and was surprised when it worked).

I don't have much to say about the other aspects of the proposal. But even just allowing mod to come before use would have avoided a really confusing stumbling block for me, and I imagine for many other users as well. So if there's no technical reason to forbid it, I think it would be a great usability win.

[Valloric]

+1, mod-after-use is very confusing to newcomers.

[arielb1]

+1, restrictions are confusing and seem stupid.

[tbu-]

@Valloric @arielb1 On the other hand, having one preferred style really helps readability.

[blaenk]

Style is good but it shouldn't be enforced that way. We already have some style guides and conventions that @aturon is working on. A better case can be made, in my opinion, to fix this and use as style the "logical" or at least historical (from other languages) method of use after mod.

Any abitrary rules can be chosen as the style, we may as well choose ones that seem to make sense.

[tbu-]

@blaenk You suggest that the current rules were made up from nothing, but in fact they were the result of import shadowing working other than people believed.

[blaenk]

I didn't suggest that at all. In fact, as this very RFC suggests, that reason has been invalidated by a prior RFC, perhaps better conventions can arise, as @aturon mentioned.

What I meant by "any arbitrary rules can be enforced" was that, if you really wanted to continue enforcing a given style this way, there's no reason we can't switch to the more logical ordering style and enforce that, if what you ultimately care about is having only one possible style.

[eddyb]

@sfackler there would be no more view items, which is great if it doesn't break any hypothetical extension (@nikomatsakis seems to have plans for expansion-time resolution that work with this).

[nrc]

I would like to see the ordering restrictions between mod and use statements lifted (are there also restrictions wrt other items? If so, I would like to lift those too).

I would like to see more motivation for pub extern crate - I can't think of one myself, and I'd be wary of adding it without one.

I would actually like to restrict the use of extern crate more, rather than less, and only allow them at the start of a crate, rather than at the start of any module. I believe this will make clearer the distinction between modules and crates and between extern crate and use statements. We seem to stick to this pattern in the compiler and libs and it feels right. I think because extern crate is about linking together compilation units, whereas use is about linking together modules.

[Kimundi]

@nick29581:
Assuming we lift all order restrictions and allow extern crate as an regular item anywhere.

Then the main motivation for pub extern crate is that forbidding it is an extra rule that has no other reason for existing other than "you shouldn't need this in normal code". But there are tons of language constructs to which that would apply, so I don't see a reason to single out that one corner case.

I also don't think that macros expanding to extern crate is a problem in general - its just like having a extern crate that transitively links to other libraries - you don't see all those dependencies right in the code either:

#[phase(link)]
extern crate foo; // Might link to additional libraries
foo::bar();

#[phase(plugin)]
extern crate foo; 
bar!();  // Might link to additional libraries

---

Of course, if we change extern crate to not be an regular item, but rather a special thing that creates private module paths in the crate root that need to be rexported with use manually, then thats a different story, but I wouldn't be in favor for that change as it complicates our notion of items in general.

[sfackler]

There are a couple of use cases for extern crate declarations outside of the crate root:

#[cfg(test)]
mod test {
    extern crate test;

    fn bench_thing(b: &mut test::Bencher) { ... }
}

If this change were implemented, another use case would be making macros like #[deriving(Decodable)] a little less sketchy:

#[deriving(Decodable)]
mod Foo { .. }

// expands to

extern crate serialize as gensymed_name;
impl gensymed_name::Decodable for Foo { ... }

[nrc]

We discussed this at today's meeting and we would like to accept this RFC, but without the optional lint. @Kimundi could you push a commit removing the lint from the RFC and then we'll merge. Thanks!

[blaenk]

Niiice. Good work everyone!

On Tuesday, October 21, 2014, Nick Cameron notifications@github.com wrote:

We discussed this at today's meeting and we would like to accept this RFC,
but without the optional lint. @Kimundi https://github.com/Kimundi
could you push a commit removing the lint from the RFC and then we'll
merge. Thanks!

—
Reply to this email directly or view it on GitHub
#385 (comment).

• Jorge Israel Peña

[aturon]

Agreed, really glad to see this moving forward!

[Kimundi]

@nick29581: Done, glad to hear it got accepted :)