Skip to content

Inconsistency in whether methods of shadowed traits are usable #31379

Closed
#31908
Closed
Inconsistency in whether methods of shadowed traits are usable#31379
#31908
Labels
A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)P-mediumMedium priorityT-langRelevant to the language team

Description

@jseyfried
jseyfried
opened on Feb 3, 2016

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?

Activity

  1. jseyfried commented on Feb 3, 2016

    @jseyfried
    jseyfried
    on Feb 3, 2016
    ContributorAuthor

    cc @nikomatsakis

  2. nikomatsakis commented on Feb 3, 2016

    @nikomatsakis
    nikomatsakis
    on Feb 3, 2016
    Contributor

    cc @rust-lang/lang

  3. nikomatsakis
    added
    I-nominated
    I-needs-decisionIssue: In need of a decision.
    A-const-fn
    on Feb 3, 2016

  4. nikomatsakis commented on Feb 3, 2016

    @nikomatsakis
    nikomatsakis
    on Feb 3, 2016
    Contributor

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

  5. dirk commented on Feb 3, 2016

    @dirk
    dirk
    on Feb 3, 2016
    Contributor

    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?

  6. bluss commented on Feb 4, 2016

    @bluss
    bluss
    on Feb 4, 2016
    Contributor

    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.

  7. nikomatsakis commented on Feb 4, 2016

    @nikomatsakis
    nikomatsakis
    on Feb 4, 2016
    Contributor

    @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?

  8. bluss commented on Feb 4, 2016

    @bluss
    bluss
    on Feb 4, 2016
    Contributor

    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.

  9. nikomatsakis
    added
    T-langRelevant to the language team
    on Feb 25, 2016

  10. nikomatsakis commented on Feb 25, 2016

    @nikomatsakis
    nikomatsakis
    on Feb 25, 2016
    Contributor

    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?

  11. nikomatsakis commented on Feb 25, 2016

    @nikomatsakis
    nikomatsakis
    on Feb 25, 2016
    Contributor

    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.

  12. nikomatsakis commented on Feb 25, 2016

    @nikomatsakis
    nikomatsakis
    on Feb 25, 2016
    Contributor

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

    triage: P-medium

  13. rust-highfive
    added
    P-mediumMedium priority
    and removed
    I-nominated
    I-needs-decisionIssue: In need of a decision.
    on Feb 25, 2016

  14. jseyfried commented on Feb 25, 2016

    @jseyfried
    jseyfried
    on Feb 25, 2016
    ContributorAuthor

    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?

  15. bors
    added a commit that references this issue on Mar 25, 2016

    Auto merge of #31908 - jseyfried:disallow_shadowed_traits, r=nikomats…

    64a13a4
  16. bors
    closed this as completedin #31908on Mar 25, 2016
  17. RalfJung
    added
    A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)
    on Dec 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)P-mediumMedium priorityT-langRelevant to the language team

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions