Flag for error on reified dynamic

[vsmenon]

Provide an static checking option to throw an error on any code that may instantiate a reified dynamic. E.g.,

typedef int Int2Int(int x);
void foo() {
  var f1 = (x) { ... }; // Error - type is dynamic -> dynamic
  Int2Int f2 = (x) { ... };  // No error - type is int -> int
  ...
  var l1 = [1, 2, 3]; // Error - type is List<dynamic>
  var l2 = <int>[1, 2, 3]; // No error - type is List<int>
}

This depends on:

• generic methods Statically type check "generic" methods  #300
• better closure inference Downward inference of parameter types #203 Remove UninferredClosure type #290 Downward inference into closures doesn't handle returns #308

[vsmenon]

@leafpetersen

Would this even let us write:

void bar(List l) {
}

? The reified type of bar is List<dynamic> -> void.

[jmesserly]

I'm not sure that would be a problem, as it's just the type annotation. The issue would only come up when you're creating instances of generic types.

[leafpetersen]

We had some discussion offline, but following up with some additional thoughts. In general, yes, there is a problem with using List in the type of a function, if you're trying to avoid reified dynamic with the intention of allowing unconstrained (or less constrained) is and as checks. Consider:

typedef List<int> F();
List foo() {};
var b = foo is F;

The VM will say that b is true, DDC will say it is false. I believe that in principle we could allow contra-variant reified uses of dynamic, since the reified types will only be used for:

• Instance of checks, in which case the reified function type is on the left side of a subtype check, and hence the argument types will be on the right hand side of the subtype check
• dsend/dcall checks, in which case the reified argument types will be on the right hand side of the subtype check.

So for example:

typedef void F(List<int);
void bar(List l) {};
var b = bar is F;

Here, the VM and DDC will always agree on the value of b.

I'm not entirely sure that it's worth allowing this level of granularity - it feels a little hard to explain why some uses of List are ok, and others aren't. On the other hand, it is kind of sensible - it's essentially saying that consumers are allowed to be permissive (claim to take any List), but that producers have to be strict (say exactly what they produce).

[jmesserly]

moved to sdk: dart-lang/sdk#24712, dart-lang/sdk#25573