[analyzer] Missing error for generic function instantiation on function object

[eernstg]

Consider the following program:

X id<X>(X x) => x;

void main() {
  int Function(int) f = id; // No problems, instantiates `id` as `id<int>`.
  var idVar = id; // Tears off `id`, yielding a generic function object.
  int Function(int) g = idVar; // Error.
}

The initialization of g is a compile-time error, because idVar is a variable and not a function declaration. However, the analyzer (as of commit ffde158) does not report any errors for this program.

With --enable-experiment=constructor-tearoff we should get an error at the explicit instantiation idVar<int> as well, and that error is also missing. Note that this question was discussed here.

Note that this should not be a breaking change, because the CFE already reports this error.

[srawlins]

Thanks for the report, @eernstg . I'm trying to figure out from the spec what the error condition is.

Let f of the form [...] be an expression that denotes a declaration of a local function, a static method, or a toplevel function, and let G be the static type of f. Consider the situation where G [is a generic function type] and the context type is a nongeneric function type F. In this situation a compile-time error occurs except when the following step succeeds: Generic function type instantiation. [...]

Since, as you say, idVar does not denote a declaration of a local function, a static method, or a toplevel function, then we are not in this situation, and the mentioned compile-time error does not occur.

[eernstg]

The error condition is that idVar does not denote a declaration of a local function, a static method, or a toplevel function, and in that case we always get a compile-time error (we're trying to assign a generic function to a variable whose type is a non-generic function type, or trying to pass an actual argument or returning a value, etc., in a similar setting, so it's just a type mismatch).

When we operate on a local function, a static method, or a toplevel function, we get a compile-time error unless generic function type instantiation succeeds. (That is, in that particular situation we get a second chance, even though there is a type mismatch: We might be able to "repair" the type mismatch using a generic instantiation).

[eernstg]

I'm afraid this rule is getting reversed: The language team queried the CFE and backend teams about the need to have the restriction that "we can't perform a generic instantiation on an existing function object" (we've had this rule in the specification for years, but implementations did not enforce it consistently). It turns out to be unnecessary, so we are working on removing that restriction. Cf. dart-lang/language#1812.

I think this is a useful change, we're removing a limitation which was conceptually unjustified (surprising, and based on implementation considerations), and now those implementation considerations turn out to be irrelevant after all. So we might as well just remove the limitation.

So I'll close this issue.