-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Open
Labels
P2A bug or feature request we're likely to work onA bug or feature request we're likely to work onarea-devexpFor issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages.For issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages.devexp-linterIssues with the analyzer's support for the linter packageIssues with the analyzer's support for the linter packagetype-enhancementA request for a change that isn't a bugA request for a change that isn't a bug
Description
Take this example:
extension E on String {
void m() {}
}Today, you can refer to m in a doc comment reference by the extension name (/// [E.m]), but not by the extended type's name (/// [String.m]).
I think it should be perfectly logical to refer to an extension member by the extended type's name. But there may be some quirks. E.g. given two extensions, E on List<int> and E on List<bool>, each with a member named m. What does /// [List.m] refer to? There are rules about resolving extension members and "specificity," which can probably apply without modification to comment references. We just have to start with a rule about instantiating the type to bounds. And probably make it non-nullable, so that it can refer to an extension E on String?.
FMorschel
Metadata
Metadata
Assignees
Labels
P2A bug or feature request we're likely to work onA bug or feature request we're likely to work onarea-devexpFor issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages.For issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages.devexp-linterIssues with the analyzer's support for the linter packageIssues with the analyzer's support for the linter packagetype-enhancementA request for a change that isn't a bugA request for a change that isn't a bug