Hmm this is swaying me to feel about equally happen with std:iter as I would be with :std::iter, since I agree that syntax highlighting would make these very distinct.
I presume crate:module would also be how this works, what about the "dynamic mounts" self and super? Considering that they already work with double colon, and super can be repeated (super::super::module)? I have no presumption, just want to know what you're thinking.
Does any other language use : for this purpose? We chose :: for familiarity. The only language I can think of that doesn’t use : or . is PHP, which used \ to uh, much derision from many people 
I’m reasonably afraid that will happen here too. For this reason, I much prefer :: to :.
It also seems a bit weird that the crate is somehow not like the rest of the path.
I agree, at first it was really confusing when I read that crate and extern were part of the path. I would rather write something like:
use(crate) file_read::for_each_line;
use(extern) {
regex::Regex,
std::{
env,
process,
io::{self, Write}
},
}
// or
use(extern) regex::Regex;
use(extern) std::{
env,
process,
io::{self, Write}
};
@mrborrowck Oh, I like that! Unambiguous prefix at import site, but doesn’t change how they look inline.
Regarding the crate-following :, for some reason I feel like it should be spaced:
use crate: file_read::for_each_line;
use regex: Regex;
use std: {
env,
process,
io::{self, Write}
}
But that’s a little awkward (the space in : {} is a bit jarring), and looks odd as part of type ascription in other places:
let x: std: io::Result<_> = ...;
I think there’s ambiguity on stable with let, as in let foo: bar = baz. That is, the following compiles on stable:
mod m {
pub const X: () = ();
}
fn main() {
let m::X = ();
}
By itself, crate_name: syntax seems OK to me, but it does seem slightly inconsistent with : and ::
To me, there’s always been an analogy to “drive volumes” here.
FWIW, I find UNIX's leading / so much more beautiful than the windows convention with drive letters.
I think something similar was already proposed in earlier threads, but I would like to propose it again:
// `[]` is a short-cut for `[crate]`
use [] file_read::for_each_line;
// no need to use [..] for relative imports
use super::Foo;
use self::bar::baz;
use [regex] Regex;
use [std] {
env,
process,
io::{self, Write}
};
let x: [std] io::Result<_> = ...;
In let expressions it looks a bit weird, but I think it’s fine, as it will be an incentive to use explicit import.
Prefixing a path with double colon (::) in C++ means "look in the global namespace", so using a double colon will get even extra familiarity from C++ folks if it means roughly the same thing in Rust.
I think this could be pretty nice if one considers self and super as modules:
// double colon after modules
use self::StatementKind::*;
// single colon after crates:
use crate:mir::StatementKind::*;
use std:collections::BTreeMap;
Syntax highlighters would probably colour the crate part of a path could differently.
I quite like the idea of the crate as a "drive volume". It's shorter and more to the point than the noisy, leading ::.
How about using a forward slash after the crate?
use crate/mir::StatementKind::*;
use std/collections::BTreeMap;
// And double colon after modules:
use self::StatementKind::*;
A slash would make use in expressions ambiguous, just like a colon is ambiguous with type ascription.
One reason to be cautious here: consider that we already get confusing error messages due to typos like Box:new. I suppose though that we can probably detect this scenario and be smart about the error we give ("no crate named Box, did you mean to use ::?")
(FWIW the options which twiddle bits of non-alphanumeric syntax in paths, like single colon or [foo]:: or such, mostly weird me out. I haven’t developed any strong preferences among the other options.)
I’d like to rearticulate one point: I agree with @matklad that all crates should be at the same level. E.g. ::crate::* and ::regex::*, or whatever option ends up being chosen. crate::* and extern::regex::* put the crates at different levels, which feels wrong to me.
I don’t really care how we get there, but I am very loosely in favor of dropping/deprecating the implicit leading :: in use paths. It being allowed but not having any meaning threw me for a loop initially.
Requiring a leading :: for imports sounds exhausting, but I saw it mentioned upthread, and I really like how it works if we allow bracketing use statements:
use {
::std::{
io::Read,
io::Write,
},
::crate::root_import,
my::local_import,
};
// Additional use blocks allowed.
// Braces can be omitted for single imports
use ::absolute::abs_import;
// Read, Write, root_import, local_import, abs_import
Leading :: is fewer characters than use, so absolute imports in this scheme are still as easy to type.
My preference for this form is how discoverable it makes the absolute/relative path rules. It’s a syntax you can easily “twiddle with prefixes” to get things to work. (Fiddling with prefixes is a huge part of how I learned Rust!) And the compiler can easily suggest how to correct your syntax.
Also, there’s little new syntax added. The crate reference is the newest concept, one which is convenient and a feature I’ve opted into. (Requiring extern would be a feature with less obvious upside to opt in to.) Otherwise users actually need to remember less about how paths work than they did before.
Lastly, being able to hoist ::absolute::module::path invocations from the middle of code into the use block verbatim is a nice touch in making the language consistent.
These are some of the upsides I’d be looking for in any new scheme—as little new syntax as is suitable for an epoch, be as easy to type out, and have benefits for users who switch to a new scheme.
Edit: To strengthen the association between a leading :: and a path name, I would not be in favor of letting a to-level :: be grouped, since a tendency would exist to use it and thus make less clear relative vs. crate-level imports:
// Allowing leading :: would make it hard to see the two Write imports differ
use ::{regex, std::io::Write, other_crate}; // use std crate, then its import io::Write
use {std::io::Write}; // local module, but visually looks like above!
All right, this thread seems to have died down, so let me try and take a stab at summarizing what people were saying. Let me know obviously if you feel I left something out!
Also available in a gist, where the formatting is slightly better.
Let me first re-summarize in a very short-hand form the set of “major proposals” that I’ve seen.
| Name | Crate-local use | External use | External in fn body |
|---|---|---|---|
| Today | use foo::bar; |
use std::cmp::min; |
::std::cmp::min |
| leading-crate | use crate::foo::bar; |
use std::cmp::min; |
::std::cmp::min |
leading-::
|
use ::crate::foo::bar; |
use ::std::cmp::min; |
::std::cmp::min |
| leading-extern | use crate::foo::bar; |
use extern::std::cmp::min; |
extern::std::cmp::min |
leading-:
|
use :crate::foo::bar; |
use :std::cmp::min; |
:std::cmp::min |
suffix-:
|
use crate:foo::bar; |
use std:cmp::min; |
std:cmp::min |
[crate] |
use [crate]::foo::bar; |
use [std]::cmp::min; |
[std]::cmp::min |
[] |
use []::foo::bar; |
use [std]::cmp::min; |
[std]::cmp::min |
Here was the post proposing each variant, and a few other notes:
:: was proposed by @Matklad
: was proposed by @withoutboats,
along with numerous other syntactic variants: was described by @aturon here
[crate] and [] were proposed (not initially, but most recently) by @arielb1 here
(There was one proposal I saw but did not include, which is
this one by @dhardy.
I’m not sure that I fully understood it. I think it is saying that
we change was use foo::bar means, but still permitting ::foo::bar
to be ambiguous, and hence to be leaning quite heavily on fallback –
not just for a transition, but forever?)
Based on the comments made so far, I think there are a number of axes on which we can compare the proposals.
The first observation is that the proposals can be broken into two
major category. Most of the proposals enjoy the 1path property,
which basically means that the same paths work in function bodies and
use statements. This means that we can potentially – eventually –
support use foo::bar with the same meaning as use self::foo::bar.
In order to make this transition, though, we have to disallow use foo::bar as legal syntax for an absolute path by the time the next
epoch starts.
Note that we don’t have to actually decide whether to permit relative
paths in use statements yet. What we do have to decide is whether or
not to clear space to permit us to add it during this epoch. We could
decide to defer this until the next epoch, and thus allow the current
forms and the new forms to co-exist for longer. (Update: See also the
note at the end, “on the cost of transition”.)
Although it does not have the 1path property, the leading-crate
proposal does offer the smallest transition from today’s
syntax. This because things like use std::cmp::min still work. All
other things being equal, it seems clear that less transition is
better.
It seems like we can order the amount of transition as follows:
:::
use change, but to a form that is legal todayIt feels to me like the existence of a functional rustfix probably
makes the raw amount of change relatively unimportant. It’s hard
for me to weight the “feeling” of adopting the existing
::std::cmp::min paths more broadly versus introducing a new form.
@SimonSapin also makes the point that the precise manner of the transition matters a lot, perhaps more than the amount of change. This relates to the next point (coexistence).
Update: See also the note at the end, “on the cost of transition”.
The proposals that introduce a completely new form (everything but
leading-crate and leading-::) co-exist smoothly with existing paths,
allowing for a simpler, gradual transition. In particular, we can
trivially keep all existing paths working, but simply deprecate those
that we don’t want to support.
(Note that if we want to pave the way to 1path, we do want to make
use statements require the newer forms in the new epoch. As noted
earlier, we may prefer to leave that for another epoch.)
There are two to adopt leading-crate or leading-::. I’ll describe in
terms of leading-::, but the same applies to leading-crate. The
first is the “flag day” approach:
extern crate declarations and we
stabilize crate-local paths.use ::crate::foo or use ::std::foo.extern crate declarations that
use #[macro_import] or other things, preferring instead to use explicit macro
imports.extern crate declarations
become dead code, so you can remove them.This has three downsides:
extern crate in the leadup to the epoch.The other approach is the fallback approach. The feasibility of this approach is not yet known; @petrochenkov has indicated it may be plausible.
use ::regex::foo, we first try
to resolve in the old style. If that succeeds, we issue a
deprecation lint, but allow it to continue.
And of course there is always aesthetic appeal. To some extent, I this is a matter of “getting used to things”, but it’s importance is also not to be underestimated. If people first coming to Rust see what seems to be “heavy” or “ugly” syntax, they may leave before they have a time to get used to it and see it’s inner beauty. =)
This table summarizes the proposals in terms of the properties above. It’s hard to judge aesthetics, of course, but I’ll note some of the specific concerns that have been raised.
| Name | 1path | amount-of-transition | coexist | aesthetics |
|---|---|---|---|---|
| leading-crate | small | w/ fallback | ||
leading-::
|
yes | medium | w/ fallback | |
| leading-extern | yes | high | yes | unbalanced, long in a fn body |
leading-:
|
yes | high | yes | |
suffix-:
|
yes | high | yes |
: vs :: confusing, amb. with type ascription |
[crate] |
yes | high | yes | |
[] |
yes | high | yes |
impl extern::fmt::Debug for Bar feels
quite unwieldy. Example comment.
: vs :: confusing" comment refers to @arielb1’s
observation that, if we ever achieve 1path, then the
distinction between use foo:bar; (bar from crate foo) and use foo::bar; (foo::bar relative to local module) would likely lead to confusion.Re-reading the comments in the thread, here are some observations.
There were a few proposals for tweaks on “nested” syntax that might go along with each variant:
// Suffix-`:` proposal
use std: { ... };
// Leading-`::` proposal
use {
::crate::foo::bar,
::std::fmt,
};
I’d like to encourage everyone to actually write code using these
proposals. I’m tempted to go and implement leading-: and maybe
suffix-: as well; I’ve found that writing even a modest amount of
code is very helpful to get a stronger feeling.
I am updating this post with new proposals and notable bits of new conversation.
On the cost of transition. As discussed in this later comment by @rpjohnst and my response, a move to permit relative paths would “repurpose” existing syntax, which comes at a cost in terms of its effect on existing content in the ecosystem. Even if we want to get there eventually, it is probably wise to move slowly, to give content time to adapt: at the most extreme end, we might begin in this epoch by deprecating the “to be replaced” form, so that you only get warnings. Then, in the next epoch, we might make it a hard error initially, and replace it later on. This a knob we can turn and there was extensive conversation about the tradeoffs in the Epoch RFC itself; it seems like, especially initially, it is probably wise not to “turn too fast”, so as to avoid creating the indelible impression that epochs mean massive churn (which is not the intention).
@nikomatsakis: I’m confused about the “unbalanced” part of the “leading-extern” one. Wouldn’t everything that upholds 1path and distinguishes extern and crate-local paths be unbalanced by that definition?
Another aspect of the “amount of transition” axis is the effect on existing documentation. There is a substantial amount of example code out there on StackOverflow, in blog posts, etc. where it won’t be fixed by rustfix. My guess would be that this kind of stuff primarily uses external paths, both in uses and in expressions, so preserving those would be the least likely to break that example code.
This includes people’s habits- rustfix or no, the more drastic a change the more annoying it will be to get used to, somewhat defeating the purpose of making it to begin with. In previous discussion, it was also pointed out that some people will be maintaining code in both epochs for a while- any crate supporting an old compiler will have to remain in the old style, so maintainers will have to “get used to” the change repeatedly, every time they switch projects.
Further, despite the requirement that crates in different epochs be interoperable, some may even want to maintain code that compiles in both. For example, a crate that supports older compilers but with a feature to opt into something from the new epoch. In addition to placing some more importance on the amount-of-transition axis, this also adds a twist to the coexistence axis. For example, it softens the downsides of the “flag day” approach for crates that would be keeping extern crate around regardless. (On the other hand, at this point the range of compiler versions that will even exist with crate:: but without the new epoch is will probably be small.)
No- leading-::, leading-:, and suffix-: all uphold 1path and distinguish extern from crate-local paths. That is, ::dep::foo/:dep::foo/dep:foo vs ::crate::foo/:crate::foo/crate:foo- all use two segments for a top-level item regardless of whether they're extern or local. Leading-extern, on the other hand, is extern::dep::foo vs crate::foo- three segments for an external crate's top-level item vs two for a local one.
Along the same lines, the inverse of "long in a fn body" applies to leading-:: and leading-:- they're "long in a use." Nested imports supposedly mitigate this, but they were primarily introduced to mitigate extra textual path segments (crate or extern). Rust already has to fight a reputation for being sigil-heavy, and since most (IIRC from the previous discussion) use paths are absolute, I don't think it would be a great idea to introduce more sigils (:: or :, which is also weird) just to make them match the relatively rare case of absolute paths in expressions.
Probably…