new lint: flag "raw" generic method/tear-off invocations (a la `always_specify_types`)

[pq]

Specifically, we do not currently lint the following "raw" invocation but maybe we should?

List<T> makeList<T>() => <T>[];

void f() {
  makeList<int>(); // OK
  makeList(); // <== LINT?
}

By extension, this would likely carry over to similar advice for constructor tear-offs. (See: #58424.)

List<E> Function<E>(int, E) filledList = List.filled; // OK
filledList<int>(3, 3); // OK
filledList(3, 3); // LINT?

@davidmorgan: I believe this rule is banned internally but I wonder if you have an opinions?

@goderbauer: similarly, you all don't use this rule but wonder if you have thoughts?

/cc @bwilkerson

---

EDIT this issue started as a reflection on updating always_specify_types to catch invocations. After some feedback and consideration, the better approach seems to be a new lint.

[srawlins]

Just a semantic note, this is not a "raw" type in the sense that the strict-raw-types analysis mode considers; there is opportunity for inference.

List<int> f() => makeList(); uses inference to fill in T.

That being said, always_specify_types does seem to have a "never use inference" subtitle to it, so maybe its valid to catch such code here.

It'd be hard to land, if Flutter uses it.

[pq]

Thanks for clarifying! If not "raw", is there a better term for invocations like makeList()?

[srawlins]

I think its just an expression with an inferred type.

If inference falls back to dynamic, I'm not sure that it is proper to say "inference filled in dynamic" or "inference failed to fill anything in, which results in a fallback of dynamic." I think in the strict-inference mode, we consider it a "failure of inference" to fall back to dynamic (or the bound).

[davidmorgan]

No opinion on always_specify_types, it's in contravention of the style guide so users are on their own ;)

[eernstg]

Wouldn't it be up to some Flutter folks to make a decision about the main purpose of this lint? I would assume that this is by far the weightiest reference to always_specify_types. If that is true then this lint should basically mean whatever they want it to mean.

A different perspective on this could be "what makes sense, abstractly?", and for that I'd think that the following situation could be a relevant target: An invocation of a generic method is subject to type inference, and one or more inferred type arguments had the empty set of constraints.

In that situation the choice of actual type argument falls back on a default, and that's presumably considered to be a source of confusion and bugs. We may or may not wish to make an exception for the declared bound on a type parameter (such that we also lint the case where there is a constraint, but the only constraint is that the type argument must satisfy the declared bound).

List<T> makeAndStoreList<T>() => <T>[];

List<Object?> storedList = const [];

void otherFunction<X extends num>() {}

void f() {
  makeAndStoreList<int>(); // OK.
  makeAndStoreList(); // LINT.
  List<int> myList = makeAndStoreList(); // OK.
  otherFunction(); // OK or LINT, depending on whether the bound counts as a constraint.
}

[pq]

Wouldn't it be up to some Flutter folks to make a decision about the main purpose of this lint?

👍

@goderbauer? @Hixie? any opinions?

[Hixie]

I think it would be valuable to flag the cases we currently don't flag. As a user of the lint, I certainly wish it would flag everything (and I do sometimes notice that it doesn't).

That said, I think @srawlins is right that this would be hard to land, and I would recommend instead creating a new lint that is specifically around method calls / constructors / whatever we don't currently cover with the existing lint, so that we can incrementally migrate code to this new lint. (Certainly I wouldn't enjoy updating Flutter and suddenly finding that my projects have a thousand lints.)

Question: can "dart fix" automatically inject the currently-inferred types for this lint? It would be interesting to have a way to turn on these "give all types" lints, run dart fix and see what the inference figured out, then turn on the opposite lints and run dart fix again and have all the redundant type annotations disappear.

[pq]

Thanks @Hixie!

I would recommend instead creating a new lint that is specifically around method calls / constructors / whatever we don't currently cover

👍

This sounds like the right approach to me too.

Question: can "dart fix" automatically inject the currently-inferred types for this lint?

We don't currently have an assist to inject inferred types into generic function invocations and it's what we'd need for the kind of dart fix behavior you're after.

@scheglov, @bwilkerson, @srawlins could probably chime in on general feasibility

[bwilkerson]

I don't foresee any difficulty with implementing a fix to insert the inferred types; the information is already computed in the AST.

It will sometimes need to add an import for the types, and sometimes we won't be able to add the import, such as when the type is a private type or in an internal (in src) library. But aside from the caveats, it seems doable.