Revisiting modules, take 3

[RalfJung]

@withoutboats

Python’s import statement is an interesting example that I think is pretty good, but hard to get to for us.

However, Python also doesn't allow you to use things from another "crate" at all without importing, right? Paths inside the module are relative, and there is no "be absolute" modifier. That would be problematic in Rust at least for error messages, which may have to mention types that have not been imported but only come up due to inference.

@withoutboats

Relative imports also work, using a leading period. However, in most modules these would be the equivalent of super::, whereas for __init__.py (the equivalent of mod.rs) they are equivalent to self::. This gives . the very understandable semantics of “from this directory.”:

Ah, I never thought about this. I didn't even notice that relative imports work "differently" in __init__ vs. other files. Neat!

---

@aturon

I wonder if there’s a way to (1) keep paths for use starting at crate root, (2) keep use as items, but (3) avoid the surprise when certain things work at crate root but not deeper within the crate.

So do you mean to rule out code like this, or to somehow make it less surprising that this stops working when moved into a submodule?

mod foo {
  fn bar() {}
}
use foo::bar;

fn main() {
  bar();
}

At this point we are talking about use mystuff vs. use ::mystuff, so the question is whether it is worth to have two additional characters at almost all crate-local uses to remind us that these are absolute. Or, phrased the other way around, is some weaker form of path confusion a price worth paying for saving two characters per crate-local use?

---

@petrochenkov

[std] is already a path to crate root, no need in the weird trailing ::.

use [std]; // Equivalent to `extern crate std;`

This actually would be a special case -- the [std]:: prefix roots the path, but so far I have not seen as [std] as being an item on its own.