-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Comments
@petrochenkov might know about this |
@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 |
This is working as intended :) The thing before |
@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 |
I'm with @gnzlbg; this seems unnecessarily confusing. Intuitively, use foo::{
self,
bar,
baz,
}; , delete Edit: 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 Footnotes
|
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 theuse
statement ends with just the module/macro/function name.This causes issues with
rustfmt
'smerge_imports
option: rust-lang/rustfmt#3362If rustc is "working as intended," the behavior is such that
merge_imports
will never be able to safely createself
imports.The text was updated successfully, but these errors were encountered: