[analyzer] A function literal can have a type where an intersection type occurs

[eernstg]

Consider the following program (created by @lrhn and shown here):

void foo<V extends num>(V Function(V) f, V v) { f(v); }

void bar<T extends num?>(T v) {
  if (v != null) { // v : T & num
    foo((x) => x, v);
  }
}

This program gives rise to the following compile-time error from the analyzer (742612d) at the invocation of foo in line 5:

Analyzing n025.dart...                 1.7s

  error • n025.dart:5:9 • The argument type 'T & num Function(T & num)'
          can't be assigned to the parameter type 'T Function(T)'. •
          argument_type_not_assignable

1 issue found.

This makes sense because v has the promoted type T & num, and horizontal type inference dictates that the type of the function literal is computed in a phase after the phase where the 2nd parameter and argument (v) are processed, such that the choice V == T & num can be taken into account.

However, an intersection type like T & num should never occur as part of the type of a function object. It should only occur as a type at the top level, and it should never be reified. The fact that the error message mentions assignability to T Function(T) implies that the invocation of f is taken to get the type argument T (which is fine), but, apparently, the erasure of T & num to T did not take place during horizontal inference, and hence it ended up in the function type.

The rules about how to obtain a reifiable type from a given intersection type are not fully specified. Typically, so far, the implementations have erased X & B to X. A discussion about this topic is ongoing in #56028. It is not expected that these discussions will change the fact that intersection types cannot be reified, but it is possible that X & B could be erased to B in some situations. (For example, it would be a useful choice in the example above.)

[srawlins]

The error message is still the same. :D