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

RFC: Remove glob-import functionality completely #11825

Closed
Aatch opened this issue Jan 26, 2014 · 6 comments
Closed

RFC: Remove glob-import functionality completely #11825

Aatch opened this issue Jan 26, 2014 · 6 comments

Comments

@Aatch
Copy link
Contributor

Aatch commented Jan 26, 2014

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

@Aatch
Copy link
Contributor Author

Aatch commented Jan 26, 2014

I couldn't find an issue for this already.

@huonw
Copy link
Member

huonw commented Jan 26, 2014

#3352 is a rather confusing bug with rustc that seems to be triggered by globs. (As evidence against them.)

@metajack
Copy link
Contributor

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.

@seanmonstar
Copy link
Contributor

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 uses. If I were writing a large Rust application, just as a Java application, I would r- any PR that contains use foo::bar::*. Making this not even an option removes the argument that may come up when I r- :)

@nikomatsakis
Copy link
Contributor

I think glob imports have their place. For example, in the borrow
checker, there is a shallow tree of submodules that all make use of
data types defined in borrowck/mod.rs. It seems rather tedious and
silly to require manual importing of all these names, vs just writing
use rustc::middle::borrowck::*. I know that there are complications
in the resolution algorithm, though, and I would be more amenable to
an argument based on fundamental challenges there.

@rust-highfive
Copy link
Collaborator

This issue has been moved to the RFCs repo: rust-lang/rfcs#305

flip1995 pushed a commit to flip1995/rust that referenced this issue Sep 5, 2024
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants