Inference should flow information between arguments in a generic function call

[leafpetersen]

EDIT by @jmesserly

Inference should flow information up/down between arguments in a generic function call. This will help inference common methods like Iterable.fold and Future.forEach.

---

(original description)
We currently do downwards and upwards inference independently. This gets us a fair bit, but we should eventually integrate the two, probably following the colored local type inference approach.

[leafpetersen]

@kevmoo This is the bug for integrating inference further to make things work for fold. Here's an example pulled over from dart-lang/sdk#25491 . Currently we give no error on this since we fail to infer a type for x and hence leave it as dynamic.

void main() {
  List<int> o;
  var x = o.fold(0, (x, y) => x + y);
  List<String> y = x;
}

[kevmoo]

@leafpetersen That doesn't quite hit the same thing I'm seeing

void main() {
  List<String> o;
  var x = o.fold({}, (x, y) {
    x[y] = 'thing';
    return x;
  }) as Map<String, String>;
  _printInt(x);
}

_printInt(Map<String, String> things) => print(things);

on Dart VM version: 1.16.0-dev.0.0 (Wed Mar 9 15:04:40 2016) on "macos_x64"

[leafpetersen]

I think it does, but maybe I misunderstand. The redundant cast hint is a different issue - this is just about why it's not enough to put a type on the map literal. In your example, the cast gives inference enough context to infer the type of fold (and then you get the redundant cast warning). We ought to be able to infer the type just from the type of the receiver and the first argument - so putting a type annotation on the map literal should be enough here. It's not though - hence this bug.

Workarounds should be either typing both the map literal and the first argument to the lambda, or putting a type annotation x instead of using var.

[nex3]

@leafpetersen asked me to add this example:

/// Creates a new map from [map] with new keys and values.
///
/// The return values of [keyFn] are used as the keys and the return values of
/// [valueFn] are used as the values for the new map.
Map/*<K2, V2>*/ mapMap/*<K1, V1, K2, V2>*/(Map/*<K1, V1>*/ map,
    /*=K2*/ keyFn(/*=K1*/ key, /*=V1*/ value),
    /*=V2*/ valueFn(/*=K1*/ key, /*=V1*/ value)) =>
  new Map.fromIterable(map.keys,
      key: (key) => keyFn(key as dynamic/*=K1*/, map[key]),
      value: (key) => valueFn(key as dynamic/*=K1*/, map[key]));

/// Creates a new map from [map] with the same keys.
///
/// The return values of [fn] are used as the values for the new map.
Map/*<K, V2>*/ mapMapValues/*<K, V1, V2>*/(Map/*<K, V1>*/ map,
    /*=V2*/ fn(/*=K*/ key, /*=V1*/ value)) =>
  // [warning] Unsound implicit cast from dynamic to K.
  mapMap(map, (key, _) => key, fn);

in mapMapValues(), I'd expect inference to be able to tell that (key, _) => key has a return type of K, but currently it cannot.

[jmesserly]

Actually, let me repurpose this bug with a new subject line :)

We did integrate upwards and downwards inference. However, it is not able to flow information between arguments on an argument list, as required for several of the examples here such as Iterable.fold

EDIT: also to fix this, we'll need to spec this for a future version Dart and implement it in the new front end

[kevmoo]

The fold case is painful. Is this really area-language?

[matanlurey]

area-pain

[nex3]

This will also become a lot more relevant if we start seriously pushing for --no-implicit-dynamic.

[jmesserly]

The fold case is painful. Is this really area-language?

Yeah it's area-language. We can't do big changes to the type system in Analyzer, because it's all migrated to the new front end (thanks to @stereotype441), and we'll need to spec out (at least informally) what the new inference algorithm should be and how the rules work. The current technique is insufficiently powerful to handle fold and similar APIs. We would need to adapt some ideas from other languages/papers (e.g. C#).

[natebosch]

Has anything changed here since the last update?
Is anything likely to change here?