Least upper bound bug? Analyzer and CFE infer "Function"

[ds84182]

Try this in DartPad:

Future<void> a(String f) async {}
void b([String f]) {}

void foo<T>(T a, T b) {
  print(T);
}

void main() {
  foo(a, b);
}

I would expect the LUB of (String) -> Future<void> and ([String]) -> void to be (String) -> void. Manually providing the type argument <void Function(String)> to foo doesn't cause any errors at runtime.

Is this an implementation error or a language issue?

cc @eernstg

[eernstg]

The language specification section 'Least Upper Bounds' specifies rules for computing the upper and lower bounds, but those rules have been updated in implementations, and the current ones are not yet integrated into the language specification. See here for upcoming rules, including non-nullability.

In any case, both rulesets have the property that they yield Function when the least upper bound of two function types with distinct numbers of required parameters is computed.

But it is indeed true that void Function([String]) is a subtype of void Function(String), so the algorithm could be improved by taking this into account. It's useful to have this issue to remind us of that fact.

In any case, it will not be a least upper bound algorithm, because the computation for two interface types uses the tie-breaker rule described at the beginning of the 'Least Upper Bounds' section in the language specification.