Type annotations affects Dart VM program execution (cannot resolve class name)

[DartBot]

This issue was originally filed by [email protected]

---

This program should run without errors in production mode:

f(foo x) => x;
main() {
  print(f("yoyoma"));
}

~/projects/dart % dart test-types.dart
'/Users/olov/projects/dart/test-types.dart': line 1 pos 3: cannot resolve class name 'foo' from ''

f(foo x) => x;
  ^

I think we'd like a warning instead of an error. dartc gets this right, it seems.

[ghost]

Set owner to @crelier.
Added Area-VM, Triaged labels.

[iposva-google]

Added Accepted label.

[crelier]

It is not clear to me that this program should run without errors in production mode.

Let's consider this other program:

typedef F(bool x);
f(foo x) => x;
main() {
  if (f is F) {
    print(f("yoyoma"));
  }
}

Should this program also print "yoyoma" without error? In my opinion, it should report a compilation error that foo is not defined. Now, why should the first one behave differently?

I think that type annotations for formal parameters and function results should not be ignored, even in production mode, because these types are relevant when a function is closurized and can therefore change the behavior of a program. The same could apply to the types of fields if implicit getters/setters can be closurized (not supported yet, I think). Only the types of local variables can be ignored.

Reassigning the bug to Gilad for clarification.

---

Set owner to @gbracha.

[crelier]

One more comment:

We could state that erroneous type annotations are ignored until the type they represent is used in a type test. In that case, the first program would run without error, but not the second one. On the implementation side, this would require the introduction of a "bad type" in order to delay error reporting until a type test is applied to a "bad type".

The claim that type annotations cannot change the behavior of a program in production mode remains invalid, though.

[gbracha]

The first program should run without error. The fact that foo is undefined is NOT an error. It is a type warning.
The 2nd program has a different issue - we need to compare the type of f against the type F, and we need to decide how that comparison should work.

f is F means (foo) -> Dynamic <: (bool) -> Dynamic, which comes down to foo <-> bool (where <: is subtype-of, and <-> is assignable-to). Since foo is undefined, we need to decide how to interpret it as a type. In order to avoid spurious type errors propagating, in an optional type system one interprets undeclared types as type Dynamic (while still giving a warning where they occur). And so, we have Dynamic <-> bool, which is true.

Conclusion - the 2nd program should run and print "yoyoma".

The next question is what should happen in checked mode. The same, since checked mode simply adds more is-tests.

[gbracha]

On the other hand ...

[gbracha]

On the other hand ...

[gbracha]

On the other hand, the spec actually addresses this, and says that in checked mode, it is an error if a malformed type is used in a subtype test. In other words, in checked mode the 2nd program will fail at the point where the is test occurs.

[crelier]

Set owner to @crelier.
Added Started label.

[crelier]

Fixed in r4732.

---

Added Fixed label.