-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Closed
Labels
devexp-linterIssues with the analyzer's support for the linter packageIssues with the analyzer's support for the linter packagedevexp-warningIssues with the analyzer's Warning codesIssues with the analyzer's Warning codeslegacy-area-analyzerUse area-devexp instead.Use area-devexp instead.
Description
Take this example from the static extension spec:
import "all.dart"; // exposes extensions `Foo`, `Bar` and `Baz`.
// ...
main() {
// ...
Baz("ok").baz(); // Explicit reference to `Baz` extension.
// ...
}
- Can the extension,
Baz
, be marked@optionalTypeArgs
? (I think so)
In the context of linter rules which take @optionalTypeArgs
under consideration, and the strict-raw-types
static analysis mode:
- If
Baz<T>
is an extension on a class,C<T>
,then I thinkthenBaz("ok")
is not ok; analyzer/linter should hint/lint where appropriateBaz("ok")
is fine; inference takes place here, similar to how it does on constructors. - The extension,
extension Baz on C
, where C is generic (e.g.C<T>
), should be considered a raw type; analyzer/linter should hint/lint where appropriate. - The extension,
extension on C
, where C is generic (e.g.C<T>
), should be considered a raw type; analyzer/linter should hint/lint where appropriate.
Any of the above can be suppressed with @optionalTypeArgs
.
CC @pq
pq
Metadata
Metadata
Assignees
Labels
devexp-linterIssues with the analyzer's support for the linter packageIssues with the analyzer's support for the linter packagedevexp-warningIssues with the analyzer's Warning codesIssues with the analyzer's Warning codeslegacy-area-analyzerUse area-devexp instead.Use area-devexp instead.