C3 has "path shortening", so for example given `open(...)` in std::io::file is usually used as `file::open(...)`. If we would to write this as `file.open(...)`. Consider now the case of mistyping `open`: `file.openn(...)`. Is this (A) mistyping the function open in module `std::io::file` or is it (B) the global/local `file` is missing from the current scope?

Also, "io", "file", "random" etc are commonly used variables, so the issue with shadowing is real.

`File file = file::open(...)` is completely unambiguous and fine. `File file = file.open(...)` on the other hand would be bad.

If the language had flat modules, or no path shortening, then it would be possible.

> Is this (A) mistyping the function open in module `std::io::file` or is it (B) the global/local `file` is missing from the current scope?

D uses a spell checker for undefined identifiers, and the dictionary is all the identifiers in scope. It has about a 50% success rate in guessing which identifier was meant, which is quite good.

> Also, "io", "file", "random" etc are commonly used variables, so the issue with shadowing is real.

If the same identifier is accessible through multiple lookup paths, an error is issued. If a local variable shadows a variable in an outer scope, and error is issued.

We've developed this over several years, and it works quite well.

Path shortening can be done with:

    alias open = file.open;

or:

    import io: open;

If I would have liked, I could have done something like `import std::io::file as file;` but I noticed that we keep getting this issue that we’re renaming things all of the time, and usually in the same way. This is why path shortening is there. To directly get something like the informal `file_open` namespacing in C programs.

Standardisation of code and examples across codebases is a nice result of this too. This makes the code easier to learn and share

I feel like path shortening is the issue, and IMO it's an unnecessary feature. I don't think most programmers are bothered by the need to explicitly import what they use. I'd personally prefer to explicitly import what I use, and refer to it in whatever way the import statement would imply.

In Rust where modules share a namespace with other identifiers, I just pick different variable names, or write my imports so they don't conflict. It's not that big a deal.

If anything, my default way of working in Rust is not to type out imports by hand; I just type what I want, then let rust-analyzer prompt me with what options there are to import it from and select the one I mean, and the import gets added to the to of the file. Occasionally I'll need to edit the imports myself for some reason (like if I have a dependency that's enabled only on platforms other than the one I'm developing on), but for the most part I just don't really think about it at all. I totally agree with you that I'd be way less happy with using wildcard imports, and I often to out of my way to avoid aliasing imports by using the full path in the case of ambiguity because I personally find it easier to read something like `std::io:: Result` than `IoResult` (with a corresponding `use std::io::Result as IoResult;` when I want to have a different `Result` in scope. I don't think it's a problem that being able to alias imports like that is an option, but I just happen not to find it particularly appealing even compared to using full paths.

What works for Rust works for Rust. My intent is to make code feel similar to C namespacing. What works and what doesn’t is fairly contextual, depending other language semantics as well.