(Modules) Tracking issue for Picking a Module Path System variant

[Centril]

This is a sub-tracking issue for the RFC "Clarify and streamline paths and visibility" (rust-lang/rfcs#2126)
as well as the internals post Relative Paths in Rust 2018.

The issue deals with revamping paths and making a decision about whether we should pick:

• The uniform_paths variant.
  Proposed in Relative Paths in Rust 2018.
• The anchored_use_paths variant.
  You have to use self::, super::, and crate::, or an external crate name explicitly....
  See rust-lang/rfcs#2126).

• Implement all the things.
  • uniform_paths, #52923
  • anchored_use_paths
• Make both variants available to test in Edition Preview 2 with appropriate documentation on how to test.
• Adjust documentation (see instructions on forge)
• Pick a variant
• Stabilization PR (see instructions on forge)

Unresolved questions:

• Which variant do we pick?

[sanmai-NL]

Could you give more details about what has been implemented concretely, and what renaming operations are needed exactly? It comes down to: how can I start testing anything right now?

A priori, I vote for anchored_use_paths, for being the most explicit/teachable. One suggestion: I find the crate keyword a bit odd since it does not seem related to visibility at all. I suppose this has been debated before but it would be better if it becomes pubcrate or whatever.

[Centril]

cc @eddyb re. @sanmai-NL's question.

[eddyb]

@sanmai-NL Now that #52923 has landed, the next nightly should have both options available:

• anchored_use_paths has been the Rust 2018 default for some(?) time now
• uniform_paths you get by being on Rust 2018 and adding #![feature(uniform_paths)]

I'd suggesting trying the latter after upgrading to the edition, and report back if the ambiguity errors end up being too excessive.

AFAIK, the upgrade involves taking a Rust 2015 crate, adding #![feature(rust_2018_preview)] without changing the edition, running rustfix to apply the suggestions it gives for making same-crate paths explicit (i.e. prepending all paths that don't start with a crate name, with crate::), and only then do you switch the edition (usually in Cargo.toml) to Rust 2018.
You can remove #![feature(rust_2018_preview)] afterwards, since it's redundant.

[joshtriplett]

rust-lang-nursery/edition-guide#85

[archer884]

I absolutely despise the "anchored paths variant," and I am very excited to see that we're considering an alternative. Any alternative, honestly. >.>

...That said, uniform paths look great. :) I'd much prefer to let people use absolute paths (the anchored version) if they like, but not force people to do it.

(No idea where the appropriate place to provide feedback for this would be, so I just left it here. Sorry.)

[kohensu]

Using uniform_paths, there is an error I find confusing.
Considering:

#![feature(rust_2018_preview)]
#![feature(uniform_paths)]
use hex;
fn main() {
    println!("hex {}", hex::encode("01"));
}

I get this error:

error: import from `hex` is ambiguous
 --> src/main.rs:3:5
  |
3 | use hex;
  |     ^^^
  |     |
  |     could refer to external crate `::hex`
  |     could also refer to `self::hex`
  |
  = help: write `::hex` or `self::hex` explicitly instead
  = note: relative `use` paths enabled by `#![feature(uniform_paths)]`

whereas self::hex doesn't exist in the module.

Because the code is working without use hex maybe suggesting to remove it will be more clear.

[Nemo157]

@kohensu see #53408, I think the plan is to either special case allow that or improve the error message to just suggest removing it.

[kohensu]

@Nemo157
Sorry, I did not see that.
Thanks for the reference to the issue.

[sanmai-NL]

@archer884: What’s more interesting is your motivation to feel that way?

[Xymist]

As a user (who perhaps hasn't been paying as much attention as I should) I think the uniform_paths option feels strictly better. Special case sugar for when there's no possible ambiguity would be nice, but by no means necessary; optimising for clarity is definitely a greater win.

[eddyb]

Special case sugar for when there's no possible ambiguity would be nice

Not sure what you mean. Does #53427 (by treating each namespace independently) solve that for you?

[archer884]

@sanmai-NL: Either Eric Lippert or Anders Hejlsberg had an article on this awhile back: people want loud syntax for things at first, but then as time goes on they want the syntax to be unobtrusive and elegant instead. If we make long, annoying imports the standard (and ONLY) option, we will absolutely regret it. "Maybe not today, maybe not tomorrow, but someday." :)

[sanmai-NL]

That’s an argument from authority, and a very aspecific one. Conciseness is a criterion independent from explicitness and also from simplicity.

[archer884]

@sanmai-NL, it's not. It's just a chance for you to read the thoughts of another person who covers the issue in greater depth. Google is your friend.

[sanmai-NL]

Very poor way to argue your case. You seem not to even recall which author you mean, but you ask me to Google for something.

[archer884]

Ok, I'm done being badgered here. Glad to see rust is still so inclusive. :)

…

On Fri, Aug 17, 2018, 9:42 AM Sander Maijers ***@***.***> wrote: Very poor way to argue your case. You seem not to even recall which author you mean, but you ask me to Google for something. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#53130 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApeRmCERlVvJYp9wVS9mBYTeJaUolXMks5uRtZFgaJpZM4VxEE_> .

[liigo]

cc me

[sanmai-NL]

Sad to see how some people dramatize a technical discussion. I hope only comments that are motivated and consider the earlier discussion are taken seriously. Just chiming in doesn’t bring us any further.

[joshtriplett]

@cramertj I think that you can just use log 0.4.4 or newer, and then stop importing log::log at all, at least when you don't call it directly. From a quick look at the code you linked to, I don't see any calls to log!.

[eddyb]

@cramertj It's not suggesting ::log because you have an ambiguity in the macro namespace, not the type/module namespace.

You hit the "nested scopes" problem, where self::foo currently only looks in the same module, but use foo::...;, under uniform_paths, in the future, might end up finding foo in a scope between the current module and the import.

However, you happen to be importing the same entity, so I think we should just silence the error in that case, like we did for imports of an external crate.

EDIT: PR up at #54201.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[aturon]

See also: #53130 proposing to stabilize on uniform paths.

[Centril]

@aturon haha; came here to link to that issue as well =P

You linked to the current issue tho ;)
Here's the right issue: #55618.

[petrochenkov]

Some follow-up issues:

• #56417 Stabilize uniform paths on Rust 2018 (technical details)
• #56414 Ambiguity errors in 2018 uniform import paths are not technically necessary
• #56413 Known deviations of macro paths and 2018 import paths from the "uniform path" model