Tracking issue for RFC #2166: impl-only-use

[aturon]

This is a tracking issue for the RFC "impl-only-use " (rust-lang/rfcs#2166).

Steps:

• Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

[petrochenkov]

I'm going to implement it this weekend.

[nikomatsakis]

I was thinking about this RFC recently. I wonder if we should enable users of existing preludes to take advantage of this feature. For example, for back-compat reasons, the Rayon prelude cannot change to export _, but I wonder if on the other side we could support some notation like use rayon::prelude::* as _ -- or is that too weird?

(Note that -- with the feature as currently implemented at least -- preludes can have pub use Trait as _; and that will get picked up by a glob import.)

[petrochenkov]

One deficiency of the current implementation is that _ in use Trait as _ is not hygienic.
Normal trait imports generated by macros produce the next error that doesn't happen with _.

#![feature(decl_macro)]
#![allow(unused)]

struct S;

mod m {
    pub trait Tr {
        fn f(&self) {}
    }
    impl Tr for ::S {}
}

pub macro m() {
    use m::Tr;
}

m!();

fn main() {
    S.f(); // ERROR no method named `f` found for type `S` in the current scope
}

This is going to be fixed by #48842 or equivalent.

[nikomatsakis]

@petrochenkov

You are saying that if we alter the macro in your example to this:

pub macro m() {
    use m::Tr as _;
}

then the code will compile, right? (And that is the problem?)

In general, it seems sort of unclear whether one would expect this to work, but I guess consistency is good.

[nikomatsakis]

This is going to be fixed by #48842 or equivalent.

Why would that fix the problem?

[petrochenkov]

@nikomatsakis

You are saying that if we alter the macro in your example to this ... then the code will compile, right?

Yes.

Why would that fix the problem?

Due to attaching hygiene context to _ (#48842 (comment)).

[petrochenkov]

Actually, everything is more interesting - this bug is hidden by another bug!
Currently there's no way to use a trait in macro so that its methods are in scope after expansion of that macro.
Nothing of this works:

pub macro outer_use1($Rename: ident) {
    use m::Tr as $Rename;
}
pub macro outer_use2($Tr: ident) {
    use m::$Tr;
}
pub macro outer_use3($Tr: path) {
    pub use $Tr;
}

outer_use1!(Rename);
outer_use2!(Tr);
outer_use3!(m::Tr);

 // still a "no method named `f`" error after expanding all the macros above
S.f();