[RFC] Use one dot . instead of four dots :: in path syntax

[liigo]

I would prefer to use std.rt.io, instead of use std::rt::io. For the later, I need to press the keyboard for 3 * 2 times more. Java and C# use . to separate packages and access methods/fields too. IMO, . is 4 times better than ::.

std::task::spawn(...) -> std.task.spawn(...)

We don't really need to write so many dots in Rust source code.

[pnkfelix]

As stated, this proposal is only to change path notation in the context of use items. While the semantics of paths in the context in versus outside of use items are nit exactly the same (see e.g. #10910), I think there is still value that the path syntax in both contexts is similar. Following this proposal's suggestion would remove that benefit.

[liigo]

@pnkfelix I've changed the proposal to use . instead of :: in path syntax: std.task.spawn(...)

[pnkfelix]

So now you want to collapse the role if :: into that of .. That is a much more far reaching change and it sounds much too broad for Rust at this stage in its design.

For example: It introduces much ambiguity into the parser. Even if we ignored that and left the job of figuring out the role of each . up to the resolve stage in rustc, I am not sure how it would work, unless we also collapsed our namespaces into a single namespace, which seems very unlikely,

[liigo]

yes, need more investigation. see others comments.

[nrc]

I prefer to stay closer to the C++ heritage (::) than the Java one, since C++ is the language domain most targeted by Rust. Also I like that . clearly indicates slot access and :: indicates scoping - different operators for different things.

[flaper87]

@nick29581 I like the usage of different operators for different things too. And I also agree with @pnkfelix it's already quite late to change this and :: is not a big boilerplate.

[alexcrichton]

This has been proposed many times in the past, and this is a part of the language which is not going to change. Name resolution is quite complicated as is, and more ambiguities is burdensome on both the compiler and the programmer.