Lint generic function literal in non-generic context

[eernstg]

Consider the following program:

void foo(void Function(int) _) {}

void main() {
  foo(<X>(p) => p.whatever); // Allowed because `p` has type `dynamic`.
}

The treatment of the function literal <X>(p) => p.whatever is error prone: The context type is a non-generic function type (void Function(int)) and the function literal is generic, which gives rise to an implicit step known as a generic function instantiation that transforms the generic function into a non-generic function by providing actual type arguments for the given formal type parameters (here: a value for X is provided).

The crucial part is that the context type doesn't contribute to the choice of type annotations in the generic function literal because it doesn't "fit" (a generic and a non-generic function type are so different that no parameter in the function literal has a 'corresponding' parameter in the context type). So every parameter of such a function literal will get the type dynamic.

(It is possible to get a heads-up by enabling strict-inference, but by default this happens silently.)

The situation can very easily remain undetected because the resulting function literal uses the type dynamic for every parameter, and this gives the function literal a type which is a subtype of every function type with the same number of positional parameters and the same names for named parameters (that is: same shape, and we're happy!).

The situation further remains undetected because the body can do whatever it wants with the parameters, because they all have the type dynamic.

This means that the function literal seems to type check just fine, but it is in fact entirely unsafe.

Hence, this issue requests a lint that flags a function literal with the following properties:

• The function literal is generic.
• The context type is a non-generic function type.

It would be pragmatically useful to detect that there is no other error with this function literal. E.g., if the parameter list shapes are different in such a way that the function literal can't be a subtype of the context type (even after generic function instantiation) then we'll get a "not assignable" error (or we might get an unwanted demotion of a promotable variable). This may or may not cause the lint which is proposed here to be considered redundant.

[bwilkerson]

Am I understanding correctly?

It sounds like this is requesting a lint that would catch a subset of the issues caught by strict-inference on the grounds that strict-inference isn't enabled by default. If that's the case, then I don't understand the value proposition because the lint would also not be enabled by default.

[eernstg]

Good point! There are some cases where strict-inference won't complain:

void foo(void Function(int) _) {}

void main() {
  foo(<X>(X p) {...});
}

In this case the parameter type is given (so there's no inference, hence nothing that strict-inference can complain about), but we still have the effect that <X>(X p) {} is instantiated as (<X>(X p) {...})<Object?> which means that we might as well have written it as (Object? p) {...}.

I don't think this is particularly harmful, though, examples where it fails at run time will have to be rather obfuscated.

Very good, so I'll close this issue!

By theway, I've actually just seen this in real code, so perhaps we should push harder for enabling strict-inference. 😀