-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
RFC: Remove glob-import functionality completely #11825
Comments
I couldn't find an issue for this already. |
#3352 is a rather confusing bug with rustc that seems to be triggered by globs. (As evidence against them.) |
We don't really use globs in Servo, except in the auto-generated code bindings. It would be pretty hard for us to remove them I think. Not so much voting for globs here as hoping someone else has a good idea for how we can live without them. In general I dislike them, but they seem to have some limited use. |
I otherwise love Rust's importing syntax. Any symbol used in the module is defined in the module or I can find it by looking at the |
I think glob imports have their place. For example, in the borrow |
This issue has been moved to the RFCs repo: rust-lang/rfcs#305 |
…ns, r=Manishearth Fix manual_range_patterns case with one element at OR Close rust-lang#11825 As mentioned rust-lang#11825 `OR` can be used for stylistic purposes with one element, we can filter this case from triggering lint changelog: [`manual_range_patterns`]: not trigger when `OR` has only one element
Glob import statements are a frequent cause of confusion and bugs in Rust code. They currently exist behind a feature gate, so there is already some pressure against them.
I suggest removing them completely. The only thing I can think of that would be a significant issue about removing the glob functionality would be how it affects the prelude. However, we could just special case prelude functionality.
The advantage of this is that would make the resolution algorithm much simpler, since the glob import functionality adds significant complexity.
cc @pcwalton
The text was updated successfully, but these errors were encountered: