Revisiting Rust's modules

[arielb1]

You can do this with today’s Rust using imports with self

mod a {
    pub use self::b::c;
    pub use self::c::*;
    mod b {
        use self::c::d; // what is "c"?
        ...
    }
    ...
}

[pcwalton]

No, you can’t, because imports from parent modules are not visible in child modules.

I’m pretty unhappy that I have to defend absolute imports again. This was solved back in 2012.

[troplin]

Because when you have reexports you have no idea what a name might refer to, since you might not have resolved it yet. Cases like this were problematic:

mod a {
    pub use b::c;
    pub use c::*;
    mod b {
        use c::d; // what is "c"?
        ...
    }
    ...
}

You might think “oh, just globally iterate to a fixed point”. Yeah, we thought so too. It doesn’t work.

I think this is no problem if “relative” always means “relative to the current module”, and not “relative to the current or any parent module”.

It would just resolve to:

mod a {
    pub use ::a::b::c;
    pub use ::a::c::*;
    mod b {
        use ::a::b::c::d;
        ...
    }
    ...
}

I don’t see any problem with that. It’s what I would have expected.

[pcwalton]

Then 95% of module imports in practice will be of the form:

use super::super::super::foo::Bar;

or

use ::foo::Bar;

Not an ergonomic improvement.

[aturon]

Just a quick note: discussion has been moving extremely quickly, and I think at this point it’s best for me to spend some time writing up a fully fleshed-out blog post following up on this thread and presenting a proposal in a rather different direction. I’m gonna bow out for now.

[troplin]

Then 95% of module imports in practice will be of the form:

use super::super::super::foo::Bar;

or

use ::foo::Bar;

Not an ergonomic improvement.

IMO it is. Personally, I never use super, it smells of bad encapsulation. For absolute imports the additional :: is a rather low price and IME imports from submodules are quite frequent and those are improved a lot, you just don’t mention them.

[pcwalton]

Imports from submodules are not nearly as common in practice as imports from ancestor modules.

[troplin]

But it would remove one of the major confusions with the module system and make it consistent with how module-qualified names work. And all for a minimal price of two characters in absolute paths.

And it would be trivially implementable.

[pcwalton]

I disagree that that the ugliness is a minimal price, and it’s not backwards compatible anyway.

[troplin]

Yes, backwards compatibility is an issue. But the premise was, that relative paths are not implementable, not that they are not backwards compatible.

But I also disagree on ugliness. For me, ergonomics is does not mean less characters to type. Ergonomics for me means having a consistent model without special rules for special cases. That way I can think faster and I will gladly type a few more characters.

In that specific case, I also like the analogy to relative path file systems. Modules would correspond to directories (in fact exactly as in your proposal).

I think much of the confusion comes from the difference to how (relative) paths usually work and matching that expectation would be an ergonomic win IMO.

[pcwalton]

in fact exactly as in your proposal

I don’t have a proposal!

I don’t care that much what we do, as long as we don’t try to do relative imports with items from parent modules in scope, because that is unimplementable. I wouldn’t like having to write e.g. use ::std::fs::File everywhere, but I wouldn’t stand in the way if the entire community were united in favor of it, I guess.

[troplin]

I don’t have a proposal!

Oh, I confused you with aturon. Sorry about that!

as long as we don’t try to do relative imports with items from parent modules in scope, because that is unimplementable

And I totally agree with that. I didn’t even think that relative could be meant like this until you posted the example.

[petrochenkov]

But it would remove one of the major confusions with the module system and make it consistent with how module-qualified names work. And all for a minimal price of two characters in absolute paths.

Then ergonomic initiative 2.0 will remove these two characters again in 2022 as a boilerplate and papercut, with people -ing about writing less symbols and a few grumpy old men still nagging about consistent models and special cases.

I wonder how many of “ergonomic” features approved now will end up as “major confusions” in five years.

[arielb1]

No, you can’t, because imports from parent modules are not visible in child modules.

I’m pretty unhappy that I have to defend absolute imports again. This was solved back in 2012.

So that’s what “relative imports” meant. I guess I was lucky it was before my time.

[est31]

we reviewed and found that the majority of modules in many crates would be inline/anonymous.

I don’t think I can share this observation just yet. I think most modules would be not inline/anonymous.

What about adding inline mod syntax, without letting docs lean towards one way or another, and then letting people use it, and then in a year, evaluating how the distribution between old and new syntax is in new crates?

[ahmedcharles]

I guess I’m unsure why a backwards compatible, incremental improvement that seems relatively uncontroversial would be discarded in favor of something that’s not backwards compatible, not incremental and controversial?

I guess I’m confused. It honestly seems like this is a waste of time, cause I’m proposing things that you considered and rejected on the path to the proposal, but it wasn’t documented that it was considered and why it was rejected.

[est31]

@ahmedcharles I don’t think that this tone will really help us to attain our shared goal.

[ahmedcharles]

It seems reasonable to give someone feedback that they shouldn’t leave details out because it causes confusion and wastes time.

[aturon]

It seems reasonable to give someone feedback that they shouldn’t leave details out because it causes confusion and wastes time.

“Rejected” is too strong a word about that proposal; it may well be that some variant of it is the right way to go!

In other words, what @withoutboats said doesn’t mean “and hence we’d never consider that” but rather “and hence we ended up proposing this alternative”. But now the rationale has been spelled out, and we can dig into it further, as @est31 is.

Keep in mind that there’s limited time to write up ideas, let alone discuss all of them in a community-wide setting. On the way to a proposal, one generally throws many away. It’s just not possible for everyone to know everything that’s been discussed.

[dpc]

I guess I’m unsure why a backwards compatible, incremental improvement that seems relatively uncontroversial would be discarded in favor of something that’s not backwards compatible, not incremental and controversial?

I like inline mod for these reasons. I proposed use extern https://github.com/rust-lang/rfcs/pull/2088#issuecomment-319155032 along those lines - a modifier keyword that fixes common complain, and looks and behaves naturally.

With these two we would have backward compatible solution to some of the pains listed in http://aturon.github.io/blog/2017/07/26/revisiting-rusts-modules/, that doesn’t change things too much, but gets rid of some common boilerplate/redundancy, gets rid (supersedes) of extern crate leaving us with just two concepts: mod and use.