Inconsistency in whether methods of shadowed traits are usable

[jseyfried]

This compiles:

mod foo {
    trait IntoIterator {}    
    fn f() { Some(0).into_iter(); }
}

but this doesn't:

trait T {}
mod bar {
    use T as IntoIterator;
    fn f() { Some(0).into_iter(); }
}

More generally, a shadowed trait's methods are usable if it is shadowed by an item, but not if it is shadowed by an import.

Should methods from shadowed traits be usable?

[jseyfried]

cc @nikomatsakis

[nikomatsakis]

cc @rust-lang/lang

[nikomatsakis]

Nominating for discussion at meeting. Clearly we should be consistent. I'm inclined to think that they should not be available, ever.

[dirk]

I'm inclined to think that they should not be available, ever.

I'm of the same thoughts as @nikomatsakis. A new "thing" with the same name as another outer "thing" should not inherit/infer/have/etc. any part of that outer thing. This is the case with variable bindings, but—according to the presented opinion—it seems like it needs to be made consistent for trait bindings, right?

[bluss]

Is there a reason to shadow traits by name? What happens here is that it must find a method named .into_iter() among the imported traits, and that name has not been shadowed in any way, so it should be callable.

[nikomatsakis]

@bluss

Is there a reason to shadow traits by name? What happens here is that it must find a method named .into_iter() among the imported traits, and that name has not been shadowed in any way, so it should be callable.

Well, that's the question, isn't it. Imagine then that trait T did have an into_iter method -- would you prefer an ambiguity error here, or success?

[bluss]

Ambiguity error if T was implemented for Option<i32> in the example (and this error is already implemented). Otherwise it doesn't interfere in any way.

[nikomatsakis]

Another more challenging example might be:

mod foo {
    use path1::Trait;
    fn bar() {
        use path2::Trait;
    }
}

should the methods from path1::Trait be available, given that it is shadowed by path2::Trait?

[nikomatsakis]

My feeling is that the simplest rule is to say that methods come from "traits that are in scope", and shadowed traits are not in scope. This interpretation is shadowing of items from prelude and globs, which seem like they should clearly not count towards method resolution.

[nikomatsakis]

Discussed in @rust-lang/lang meeting and settled on "methods from shadowed traits should be unavailable".

triage: P-medium

[jseyfried]

This interpretation is shadowing of items from prelude and globs

We also want methods from path1::Trait to be unavailable (from your more challenging example), right?