Receiver Type Inference

[chloestefantsova]

This issue is created in response to #3523.

Consider the following program.

void main() {
  List<num> xs = [1].toList();
  xs.add(1.5); // Throws.
}

Currently the type inference mechanism in Dart always infers receivers of all kinds of invocations in the empty type context. So, the type literal [1] is inferred in the empty context, ultimately determining the type argument of the list literal from the types of the elements rather than from the type of the variable xs being initialized.

The current feature proposal suggests using type contexts of structural kind called context type terms that are suitable for encoding of the downwards type information for the receivers. In the example above, the structural context for [1] as the receiver of the toList method invocation can be described as {toList(): (...) → List<num>}. That structure indicates that [1] is supposed to have a member called toList that can be invoked and returns a value of type List<num> upon the invocation. The type information encoded this way can help with inferring the missing type arguments from the types hinted by the surrounding type context. To enable passing the new kind of type information between the inference phases, the current proposal suggests considering context type terms first-class type schemas in the type inferring mechanism.

As a related concern, the current feature proposal suggests replacing the currently used eager approach for deciding on the inferred type with a delayed approach, where the type information is gathered from all available sources, and the most appropriate solution to the constraint system is picked among the collected ones. The delayed approach allows combining the collected type information too, for example, when some of it comes in the form of context type terms during the downwards inference phase, and some other type information comes in the form of nominal types during the upwards inference phase.