Tracking issue for RFC 2128: Nested groups in imports #44494
Comments
aturon
added
B-RFC-approved
TimNN
added
the
C-tracking-issue
|
I'd like to work on this. |
|
@pietroalbini great! I think @petrochenkov or @jseyfried would be best equipped to writing up some mentoring notes here. But I think the general idea is going to be something like this:
|
The desugaring is done here https://github.com/rust-lang/rust/blob/master/src/librustc_resolve/build_reduced_graph.rs#L113 |
nikomatsakis
added
E-mentor
|
@pietroalbini just checking in -- any progress? Any questions arisen? |
|
I'm still working on this. I mostly updated all of rustc to support the feature, and now I started fixing a few bugs in the code. |
|
@pietroalbini how's it going? I'm just checking in -- I know you've been hard at work on this, I was just wondering if you could give a quick status update. |
|
@nikomatsakis sure! I fixed a few days ago a bunch of errors related to |
Add nested groups in imports This PR adds support for nested groups in imports (rust-lang/rfcs#2128, tracking issue #44494). r? @petrochenkov
|
The feature has been merged 🎉 🎉 |
|
Hm, I am quite surprised that neither the RFC nor the tracking issue had a single "no, we don't need this" comment... Given the amount of ❤️ on the RFC, I think that community overwhelmingly supports this feature, so my concerns are probably unfounded, but I still would want to register them. I personally am neutral or slightly negative about the usefulness of this feature. The benefits seems marginal, but there's certainly a cost to chose between several ways of writing the same import now. I already spend quite some time make imports perfect: stdlib first, then external crates, then my crate, then sort them alphabetically, then decide if I should go with On the other hand, duplicating path segments does not seem that unergonomic, especially given that you can easily sort them. |
These are all stylistic choices. You can choose not to use this new syntax. |
|
While someone can surely abuse this new syntax if they want, it can be really nice in a few cases. For example, I tend to group related imports together, so if I want to use an atomic across threads |
|
I think we should consider stabilizing this feature for the 1.25 release (this cycle). As such: @rfcbot fcp merge |
|
Team member @aturon has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
the
proposed-final-comment-period
|
@pietroalbini thanks for the info! |
…s-span, r=petrochenkov
Fix spans in unused import lint for nested groups
This fixes an inconsistency for empty nested groups, and adds a test for all the possible cases of the lint.
```
warning: unused imports: `*`, `Foo`, `baz::{}`, `foobar::*`
--> test.rs:16:11
|
16 | use foo::{Foo, bar::{baz::{}, foobar::*}, *};
| ^^^ ^^^^^^^ ^^^^^^^^^ ^
|
= note: #[warn(unused_imports)] on by default
warning: unused import: `*`
--> test.rs:17:24
|
17 | use foo::bar::baz::{*, *};
| ^
warning: unused import: `use foo::{};`
--> test.rs:18:1
|
18 | use foo::{};
| ^^^^^^^^^^^^
```
cc rust-lang#44494
…s-span, r=petrochenkov
Fix spans in unused import lint for nested groups
This fixes an inconsistency for empty nested groups, and adds a test for all the possible cases of the lint.
```
warning: unused imports: `*`, `Foo`, `baz::{}`, `foobar::*`
--> test.rs:16:11
|
16 | use foo::{Foo, bar::{baz::{}, foobar::*}, *};
| ^^^ ^^^^^^^ ^^^^^^^^^ ^
|
= note: #[warn(unused_imports)] on by default
warning: unused import: `*`
--> test.rs:17:24
|
17 | use foo::bar::baz::{*, *};
| ^
warning: unused import: `use foo::{};`
--> test.rs:18:1
|
18 | use foo::{};
| ^^^^^^^^^^^^
```
cc rust-lang#44494
|
Hmm, this feature has only been implented for two months - that seems a pretty short stabilisation period. I don't have a strong objection to stabilising, but I don't feel a rush to either - this has always felt like a marginally useful bit of syntax sugar, with some added complexity in exchange. |
|
@nrc it will still take another 3 months to actually reach stable. Given the pipeline of features we're hoping to stabilize for the epoch release, and the timeline thereof, we need to be steadily stabilizing features to avoid a last-minute rush -- particularly when they are as straightforward as this one. This feature is also quite important for considerations around the new module system path syntax. |
|
So, I'm all in favor of stabilizing this soon. However, I see that the documentation checkbox has been checked, but I can't see any links to those PRs in this issue? Does anyone have links handy, or does @rust-lang/docs need to get on it? :) |
|
@steveklabnik I think it's checked because I already prepared the snippets to be added to the various docs when I sent the original PR (available on the unstable book). I can send PRs to the various repos so the docs team can review them, after the lang team accepts the stabilization. |
|
Ah, normally the process is, PRs should be open in order for someone to be able to call for stabilizing. This is a small enough feature that I'm happy to do it after. |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
|
I'd love to get this in for the current release cycle (beta branches in about two weeks) -- anyone want to take on the stabilization here? |
|
Sure, I'll start sending out PRs. |
…ilize, r=petrochenkov Stabilize use_nested_groups As requested in rust-lang#44494. Documentation PRs already sent.
|
The stabilization PR has actually landed (and doc PRs are sent), so this is done. |
This is a tracking issue for the RFC "Nested groups in imports" (rust-lang/rfcs#2128).
Steps:
The text was updated successfully, but these errors were encountered: