You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
No warnings in extension declarations, when there are member name collisions #41878
When resolving a member m against a type T, we first look in the type T and its supertypes for a definition of m. If one is found, we stop. If no member with that name is found, then we look for an extension. So the fact that it's resolving to the members in the class is correct.
The reason there's no diagnostic when colliding is (IIRC) because those members are still accessible via an extension override such as FileSystemEntityExtension(entity).path.
But as Brian mentioned in a CL, we might want to produce a hint on declared extension members if the extended type already declares a member with the same name.
Activity
bwilkerson commentedon May 12, 2020
I think this is WAI.
When resolving a member
magainst a typeT, we first look in the typeTand its supertypes for a definition ofm. If one is found, we stop. If no member with that name is found, then we look for an extension. So the fact that it's resolving to the members in the class is correct.The reason there's no diagnostic when colliding is (IIRC) because those members are still accessible via an extension override such as
FileSystemEntityExtension(entity).path.scheglov commentedon May 12, 2020
Yes, I agree that this WAI.
But as Brian mentioned in a CL, we might want to produce a hint on declared extension members if the extended type already declares a member with the same name.
srawlins commentedon Jun 7, 2020
I've requested this lint at #58182. I think this can be closed.