Should `use super::{self, ...}` work?

[alexreg]

Obviously use super::self would be a bit redundant, but what about if you're importing lots of items from super?

We can already do something like:

use foo::{self, a, b, c};

So why not something like this?

use super::{self, a, b, c};

For reference, the specific error message on nightly is:

error[E0432]: unresolved import `super`
 --> ...
  |
1 | use super::{self, a, b, c};
  |             ^^^^ no `super` in the root

[petrochenkov]

I suppose, any sequences of super, self and other segments should "just work" ^*, similarly to how .. and . work in filesystem paths - .././src/./../README / super::self::src::self::super::README - both valid.
I't just not very useful, so nobody implemented it.
* _{unless it complicates or slows down the implementation}

cc @jseyfried

[jseyfried]

@petrochenkov
Making self and super in path interiors "just work" would be simple to implement, but I'm not sure if it would ever be useful in practice (maybe macros?).

@alexreg
One downside of allowing use super::{self, ...}; is that you can't tell what name the self is importing just by looking at the import (whereas with use foo::{self, ...}; you know it imports foo).

Also, if super resolved to the crate root, what would use super::{self, ...}; import?

[petrochenkov]

but I'm not sure if it would ever be useful in practice (maybe macros?).

Maybe macros, yes. Is path concatenation ever useful? Something like "base path" + "relative path" -> "absolute path". I don't know.
My logic is that super and self already work in path interiors sometimes

super::super::super::a
              ^^^^^ super is based on some path, not relative to the current module
a::b::c::{self, d}
          ^^^^ self is based on some path, not relative to the current module

, so maybe the restrictions on where they can be used may be lifted.
This is certainly not an urgent matter, just some reflections.

[petrochenkov]

Also, if super resolved to the crate root, what would use super::{self, ...}; import?

Empty unusable name? 😄
This doesn't work either:

struct S;

mod m {
    use super::{self as root};
                ^^^^^^^^^^^^ no `super` in the root

    type A = root::S;
}

[alexreg]

Any update on this, @petrochenkov?

[petrochenkov]

The consensus seems to always require the rename part (... as some_name) on imports like use super; or use crate; (rust-lang/rfcs#2126 (comment)).
Nothing new on the implementation front though.

I think it's possible to hack up some working solution quickly, but the proper solution (as I see it) is to avoid splitting import paths into two parts (the last segment and everything else) like it's done now (this splitting causes quite a bit of issues) and desugar
use a::b::c; into use a::b::c::{{type}}; use a::b::c::{{value}}; use a::b::c::{{macro}}; while keeping these imports "fused" for error reporting purposes.

[alexreg]

The consensus seems to always require the rename part (... as some_name) on imports like use super; or use crate; (rust-lang/rfcs#2126 (comment)).

Why the obligatory rename on super? Would parent/ancestor modules automatically be renamed, like with crates in this RFC? I can't tell.

I think it's possible to hack up some working solution quickly, but the proper solution (as I see it) is to avoid splitting import paths into two parts (the last segment and everything else) like it's done now (this splitting causes quite a bit of issues) and desugar
use a::b::c; into use a::b::c::{{type}}; use a::b::c::{{value}}; use a::b::c::{{macro}}; while keeping these imports "fused" for error reporting purposes.

If I understand this right, then yes, I tend to agree. What are the double brackets {{ for though?

[petrochenkov]

Why the obligatory rename on super?

Conservative choice avoiding issues in various corner cases (rust-lang/rfcs#2126 (comment) contains all the details).

What are the double brackets {{ for though?

Just some way to express "resolve this path only in the specified namespace" in my comment.

[alexreg]

Okay, makes sense. I think I can get on board this then.