Skip to content

Report lint when an extension member name collides with extendee member name #58182

Open
@srawlins

Description

@srawlins

Describe the rule you'd like to see implemented

See #41878 and dart-lang/language#966.

Extensions are legally allowed to declare members whose names collide with members declared on the extended class. However, this is often undesirable. A) it is difficult to call the extension member; it can only be called by explicitly using the extension's name. B) it may be accidental; it may be that in some versions of the extended class, there is no collision, and in later versions, there is. If a developer is editing an extension with a member which newly collides with another member, it would be good to know.

Extensions mean that adding a member to a class may be a breaking change for the new reason that code which previously called an extension member would now call this mysterious new member.

Examples

// package_one/a.dart in version 1.0
class C {}
// package_one/a.dart in version 2.0
class C {
  foo() => "x";
}
// package_two/b.dart
extension E on C {
  foo() => "y";
}

Libraries which import package_two/b.dart will get different behavior based on which package pub has fetched for their code's .packages file. Without any static analysis warnings, the author of package_two/b.dart does not know that their extension member overrides an existing member, when they upgrade their dependency on package_one to include 2.0.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3A lower priority bug or feature requestarea-devexpFor issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages.devexp-linterIssues with the analyzer's support for the linter packagelinter-lint-requesttype-enhancementA request for a change that isn't a bug

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions