RFC: Nested groups in imports

[petrochenkov]

This is an incremental improvement to syntax of imports.

With this RFC groups inside of braces {} in imports can be nested

use syntax::{
    tokenstream::TokenTree, // >1 segments
    ext::base::{ExtCtxt, MacResult, DummyResult, MacEager}, // nested braces
};

and globs * can be placed into groups as well

use syntax::ast::{self, *}; // * in braces

Closes #1400
Closes #1290

Rendered

[aturon]

Thanks, @petrochenkov, for hopping on this! Somehow it hadn't been targeted as part of the ergonomics initiative previously. I'm very much in favor; I've wanted this syntax many, many times.

There's not really a lot to critique here, so I'm going to go ahead and propose FCP, which will ping the other members of the lang team to review.

@rfcbot fcp merge

[rfcbot]

Team member @aturon has proposed to merge this. The next step is review by the rest of the tagged teams:

• @aturon
• @eddyb
• @nikomatsakis
• @nrc
• @pnkfelix
• @withoutboats

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.

[Ixrec]

I had no idea insta-FCP insta-PFCP was even allowed, but this is a perfect RFC to do it on.

[aturon]

@Ixrec yeah my thoughts exactly. Note though that the lang team still has to sign off to go into FCP, which is part of why I wanted to get the ball rolling right away. With luck, we'll be merging this in two weeks time...

[chordowl]

Would the following be legal under this RFC? (Without asking about if it would be desirable to use it this way ^{although I think I like this 😅})

// adapted from rand's lib.rs
use ::{
    chacha::ChaChaRng,
    isaac::{IsaacRng, Isaac64Rng},
    distributions::{
        range::SampleRange,
        Range,
        IndependentSample,
    },
    std::{
        cell::RefCell,
        io, marker, mem,
        num::Wrapping as w,
    },
};

And, if that was legal, would it also legal without the leading :: (e.g. use { /* *snip* */ })? Should it be?

Overall, I'm a big 👍 !

[petrochenkov]

@lukaramu
Yes, this should be legal, both with and without :: (unless #2126 changes something in this area, I haven't read it yet).
This is a logical extension of use ::{a, b, c}; and use {a, b, c}; which are legal currently.
(Also, see the grammar in the RFC text, it accepts the example.)

[scottmcm]

Minor thing: It looks like the grammar allows

use std::mem::{*, copy};

At the grammar level that's reasonable, but should there be a lint about it?

[retep998]

@scottmcm Do we currently lint on use std::mem::*; use std::mem::copy;? If yes, that lint should apply to that example too. If no, then that lint would have to be proposed separately.

[petrochenkov]

@scottmcm
It's assumed that code like this is reported by unused_imports lint.

https://play.rust-lang.org/?gist=eaeded63b68e2b63d84f173fce79c832&version=nightly

// use std::mem::{*, swap};
use std::mem::*; // WARN unused import: `std::mem::*;`
use std::mem::swap;

fn main() {
    let mut x = 0;
    let mut y = 0;
    swap(&mut x, &mut y);
}

https://play.rust-lang.org/?gist=5d9069fe10d07f8a3046d5a9bc82ecce&version=nightly

// use std::mem::{*, *};
use std::mem::*;
use std::mem::*; // WARN unused import: `std::mem::*;`

fn main() {
    let mut x = 0;
    let mut y = 0;
    swap(&mut x, &mut y);
}

[glaebhoerl]

IIRC how name resolution works, that's not even a useless thing to do, because if you have multiple glob imports, the explicit import of copy will shadow any other items called copy from the other globs, instead of causing an ambiguity error upon use?

[petrochenkov]

@glaebhoerl

if you have multiple glob imports, the explicit import of copy will shadow any other items called copy from the other globs, instead of causing an ambiguity error upon use

Yep, that's a valid use case too.

In general, the "don't think, desugar" seems like a reasonable approach because If some imports look suspicious in "merged" form, then they should be reported in "unmerged" form as well.

[eddyb]

I second @petrochenkov that simple desugarings help users form the intuition that "it's just a shorthand", and for refactoring the transformation is simpler for both humans and tools.

[withoutboats]

I'm pretty strongly against importing from multiple crates with a single use statements and I'd like us to consider it unidiomatic. But it makes sense for it to be allowed technically.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[tapeinosyne]

Small correction: here the path should be rustc::mir::transform::{MirPass, MirSource}.

[tapeinosyne]

The RFC is jolly good as it stands, but I am tempted to ask: are there obvious reasons not allow this in re-exports? As in

pub use module::this_here_fn;
pub use module::yonder::{Struct, Trait};
pub use module::yonder::window::*;

becoming

pub use module::{
    this_here_fn,
    yonder::{Struct, Trait, window::*},
};

Such "re-export lists" would work nicely with the façade pattern. Moreover, once nested imports land on stable, it would feel rather inconsistent to have use declarations nest in one direction, but not the other.

[retep998]

@tapeinosyne I don't see anything in this RFC that explicitly restricts this from working with visibility modifiers, so I don't see why your example wouldn't work when this RFC is eventually implemented. Might be worth clarifying in the RFC that this feature can be combined with visibility modifiers just fine.

[tapeinosyne]

@retep998 Explicitly restricts, no. Carefully avoids mentioning, yes. Imports and imports only are explicitly mentioned in the title, the examples, and the syntax section of the Reference-level explanation. (As I understand, pub use is simply an import made public, but the RFC may be approaching things from a broader perspective. Either way, as you say, it's worth clarifying.)

Besides, re-export lists look a bit like a little zombie hand sticking out of the grave of export lists long gone, which may unduly faze some…

[withoutboats]

@tapeinosyne It may be worth calling out explicitly, but I guarantee given the author that this was assumed to cover pub use.

[petrochenkov]

@tapeinosyne

Carefully avoids mentioning, yes.

The grammar explicitly contains visibilities, but I should make it more prominent, yes.
This change is independent from pub, so it didn't occur to me to mention it specifically.

[tapeinosyne]

@petrochenkov The grammar explicitly contains visibilities

Oh, you are right. Apologies, I must have missed that.

[crumblingstatue]

👍 from me.

It's not something that's used often, but there are some common patterns that it makes prettier / less painful to write, and (probably) doesn't add too much complexity to the import system.

One example that always annoys me is

use std::io;
use std::io::prelude::*;

which can now be simply

use std::io::{self, prelude::*};

[rfcbot]

The final comment period is now complete.

[aturon]

This RFC has been merged! Tracking issue.

Thanks @petrochenkov!