Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

use some::module::self; and use some::module; not semantically equivalent #60941

Closed
jrobsonchase opened this issue May 18, 2019 · 5 comments
Closed
Labels
T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@jrobsonchase
Copy link

In instances where a path can represent both a module and a function or macro, the self import will only import the module and not the function/macro, whereas everything will be imported if the use statement ends with just the module/macro/function name.

This causes issues with rustfmt's merge_imports option: rust-lang/rustfmt#3362

If rustc is "working as intended," the behavior is such that merge_imports will never be able to safely create self imports.

@jonas-schievink jonas-schievink added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label May 18, 2019
@jonas-schievink
Copy link
Contributor

@petrochenkov might know about this

@jrobsonchase
Copy link
Author

@Nemo157 referred me to this issue that came up before, but I couldn't find any reference in any of the linked issues to how self imports are supposed to be treated.

@petrochenkov
Copy link
Contributor

This is working as intended :)

The thing before :: (e.g. foo in foo::bar or foo::self) is always a type/module, so path resolutions can never "bifurcate" in the middle, so a path can resolve to 3 things at most, determined entirely by the last segment.

@gnzlbg
Copy link
Contributor

gnzlbg commented May 22, 2019

@petrochenkov This feels like a big subtlety in how imports work, could we do better here, or what's the value of this distinction and how does it outweigh its costs in terms of teachability?

For example, when the last component of a path is self, the previous component is interpreted as "any item", and if multiple items with the same name are found, all of them are imported.

@jrobsonchase
Copy link
Author

jrobsonchase commented May 25, 2019

I'm with @gnzlbg; this seems unnecessarily confusing. Intuitively, use something::{self}; should be the same as use something;, and I feel like that's how the vast majority of people interpret the syntax. It's going to get extra weird when people start taking imports like

use foo::{
    self,
    bar,
    baz,
};

, delete bar and baz, and then get confused when rustfmt does the right thing and leaves them with use foo::{self};. At least the opposite case with merge_imports = true (use foo::bar; use foo::baz; use foo -> use foo; use foo::{bar, baz};1) doesn't look obviously wrong.

Edit: use foo::{self}; seems especially wrong considering that use foo::self; isn't allowed.

Also, it seems inconsistent since I don't see an obvious way to get at just a function or macro, while you can get only the module with self imports.

Footnotes

  1. Not yet fixed, rustfmt still produces self imports

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants