Relative paths and Rust 2018 `use` statements

[nikomatsakis]

I’d be very surprised if that doesn’t keep working, since it works today. Why would that not keep working?

That does not work today. You need to write use self::Enum::Variant today?

[matklad]

You can always rename the dependency foo rather than shadowing.

Fair enough; I hadn’t considered that possibility. Still, I don’t think we want to go there any time soon.

I am not sure I understand the thought here exactly, but I think we don’t need to go anywhere? You already can rename dependencies in Cargo.

[josh]

https://play.rust-lang.org/?gist=6e5f8853be72022de6164991b3e867a5&version=stable&mode=debug&edition=2015

We shouldn’t break that. And I don’t see any reason why we’d need to. This proposal can easily preserve that.

(Or perhaps we’re using “today” differently. Are you talking about the 2018 edition preview, rather than current stable Rust? If we’ve broken that in the 2018 edition preview, all the more reason to fix it before we ship.)

[wycats]

I think it’s pretty unfortunate that we can’t make use inscopename::foo work, because I find @josh’s mental model here very appealing.

[nikomatsakis]

We shouldn’t break that. And I don’t see any reason why we’d need to.

That happens to work in the root module, but not other modules. We are already breaking that in Rust 2018 anyhow, where you must write use crate::Foo instead (or use self::Foo). =)

[Centril]

So… I’m sorry to be the one to say this but…

2018-08-02: Edition preview 2
2018-09-13: Edition release candidate (RC)
2018-10-25: Edition release

Changes discussed here sound nice to me, but don’t forget about the time pressure we’re under.

I’d like to hear from @nikomatsakis about the time this will take and impending deadlines…

Rust 2018: the home stretch

With the first Edition Preview out last week, it’s time to firm up plans for completing Rust 2018! This post lays out some ideas on how to do that. Proposed milestones Based on our current trajectory, I propose we target the 1.30 release on 2018-10-25 for announcing Rust 2018 to the world. That target, based on team discussions, is feasible, but it also leaves room for an additional release cycle within 2018 if necessary. There are a lot of moving parts (and teams!) involved in this release, s…

[matklad]

Overall, I really like this idea!

I am a bit worried by the enum problem: the proposal increases uniformity in the common case, but it also creates more special cases.

For locality, I think we can use code style to gain it back!

I think most people, myself included, write extern crate, use and mods in this order:

extern crate foo;

use bar::baz;

mod quux;

and then struggle with putting use self::quux::Spam either with other uses, or with mod quux; Just today I’ve found out that there’s in fact an alternative style of putting mods before usees:

extern crate foo;

mod quux;

use bar::baz;
use self::quux::Spam;

I personally find this style much better (although I’ve been using the opposite one for several years!), and, with this proposal, it’ll actually provide locality as well because, typically, you’ll only need to scan a small mod section before uses.

[josh]

I see.

Given the proposal under discussion here, which specifically changes name resolution in use to start from the local module, it’d be consistent to make enum Enum { ... } use Enum::*; work no matter what module you’re in. Is there some obvious reason we can’t do that?

[josh]

One day I hope to fix that by no longer having to write mod quux; at all, but I have no intention of mixing that with this proposal.

[nikomatsakis]

Is there some obvious reason we can’t do that?

I don’t think it’s any harder to support enums than it is to support modules (I have concerns about path that I cited here). I just thought you explicitly didn’t want that, since @aturon wrote:

A module-local path starts with the name of an immediate submodule (not any other declaration), the name of an external crate, or the keyword crate or super (no self )

Note the “not any other declaration” part.

[nikomatsakis]

Indeed, the idea of making any changes here makes me very nervous. I think it’s better to think about this as a “post edition” sort of change.

[wycats]

This exploration is coming from feedback from people attempting to use the preview, so I think the process is working ok. There is, of course, a very high bar to making changes at this point.

As a daily user of the preview, I messed up use EnumType::* 100% of the time at first until the compiler reminded me to insert the self::* so that’s one data point.

The overall big improvement to unify the semantics of the two kinds of paths makes it easier to forget about the remaining differences, in my experience so far.

[josh]

I think that’s purely because it’s easy to forget about use Enum::*; as a thing. Neither of us talked about that at all when we were formulating this proposal.

[aturon]

Note: several of the discussion participants ended up talking in high bandwidth on the Discord, and I’m now working on writing up a revised proposal. Once that’s ready, I’m going to close this thread and open a new one (to keep things manageable).

[illustrious-you]

Sounds like the conservative route should bear some consideration. Would @gbutler’s idea work here?

• use extern::<crate name>::<rest of path>
• use crate::<rest of path>
• use super::<rest of path>
• use <relative path>

With 1 tweak: leave use self::<rest of path> in. This would cause all paths in 2018 to be explicit, until it can be determined which root (or roots) should support elision.

[tom.prince]

I have no strong thoughts on this, other than to point out that python originally had imports that worked as described here, and decided to switch to something like the current 2018 edition plan. Before going down this route, it would make sense to consider the reasons that python decided to move away from what is being proposed here.

[aturon]

Before going down this route, it would make sense to consider the reasons that python decided to move away from what is being proposed here.

Rationale from the PEP:

As Python’s library expands, more and more existing package internal modules suddenly shadow standard library modules by accident.

It’s a particularly difficult problem inside packages because there’s no way to specify which module is meant.

The second problem doesn’t apply at all; the first problem feels a lot different in Rust, since std isn’t growing and the conflicts would be with library names (which also require an explicit addition to Cargo.toml).

My feeling is that, as long as we have ergonomic unambiguous syntax, these conflicts shouldn’t be an issue.

[gbutler]

python originally had imports that worked as described here

When you say, “described here” do you mean the 2018 Current vs new possible proposal or do you mean the alternative with explicit absolute path indicators everywhere that absolute paths are desired?

Before going down this route

Which route are you referring to when you say, “this route”?

python decided to move away from what is being proposed here

Which proposal are you saying Python moved away from?

Sorry, I’m just not sure I understand which proposal is which in what you said and how Python’s previous proposals vs current situation relate to the 3 different alternatives discussed in this thread.

[gbutler]

as long as we have ergonomic unambiguous syntax

Agree. But, I don’t agree that syntax that can be interpreted as either referring to the sub-module or an external crate, and that has to have a rule that chooses one over the other (with a lint) is “unambiguous syntax”.

Unless I’ve misunderstood something, the current 2018 proposal and the modified proposal would allow a relative path (not a use) to be interpreted as either an external absolute path within a different crate or a local sub-module path. In either case, you arbitrarily have a rule that says how it should be interpreted. I wouldn’t consider that unambiguous.

[aturon]

But, I don’t agree that syntax that can be interpreted as either referring to the sub-module or an external crate, and that has to have a rule that chooses one over the other (with a lint) is “unambiguous syntax”.

Oh yes, what I mean is specifically having some syntax you can use to be explicit about exactly this point. That’s separate from whether you always have to use that syntax.