Description
Summary
Dart 2.0.0 made the clauses implements Function, extends Function, or with Function have no effect (spec section 19.6). There was a bug in how this was implemented under the common front-end. We have fixed the issue, but this may be visible on some rare scenarios and may require fixes on your application.
Details
Since Dart 2.0.0, the language specification indicates that instance types are not a subtype of Function. However, Dart still allows the function call syntax to be used to invoke the call method on object instances of classes that have such a method. Since those instances do not implement the Function type, our tools have special support for it by tearing off the call method and using the regular function invocation on it.
Recently we found a bug showing that our tools didn't completely ignore some implements Function and similar clauses in the code. We have fixed this, but as a result there were new cases where our tools will tear-off the call method. In some rare cases, that can cause a breaking change.
What can break?
Inspecting the runtimeType of variables typed as Function may change.
For example, consider this program:
class MyClass1 implements Function {
void call() {}
}
class MyClass2 {
void call() {}
}
main() {
Function f1 = MyClass1();
print(f1.runtimeType);
Function f2 = MyClass2();
print(f2.runtimeType);
}Before the fix this program printed MyClass1 and () => void, after the fix it will print () => void twice.
Tear-off the call method on JS-interop types (web only).
JS-interop classes currently do not support tear-off methods, and as a result, using a js-interop type where Function was expected will not work.
We know of one such rare scenario: when modeling JavaScript constructor functions via JS-interop, some APIs in dart:js_util incorrectly expected those instances to have the Function interface. Those APIs have been fixed, but similar patterns on user code could run into the same problem.
Possibly compile-time warnings. At this time we are also considering adding to our tools a warning to alert when programs contain clauses such as implements Function. If a tool chain treats warnings as errors, this too could potentially be a breaking change.
Mitigation
The main action to take is to remove theimplements Function, extends Function, and mixin Function clauses, and then iterate on fixing downstream issues specific to your application, if there are any.