DDC: JS-Interop tearoffs cause type errors

[matanlurey]

I had code like the following:

sink.stream.listen(worker.postMessage);

... and had to change it to the following to get it to work/not error out:

sink.stream.listen((m) => worker.postMessage(m));

[jmesserly]

If you have more info (like a full repro) I'd be curious to see it. JS functions are supposed to be able to subtype all Dart functions.

Note that JS "tearoffs" obey JS rules: they don't bind this. That is intentional, as far as I know (CC @jacob314 ). I'm not sure the best way to trigger bind on the JS function from Dart.

[jacob314]

yes JS tearoffs intentionally follow JS function tearoff semantics not Dart function tearoff semantics and in Dart 1.0 there was definitely no way we could make them follow Dart semantics as Dart 1.0 is too dynamic so this is ambiguous at compilation time.

For example, there might be another JS interop class where
postMessage is a getter that returns a Function in which case binding "this" is definitely not what you want.
For Dart 2.0 it could be reasonable to bind this in a tearoff of a JS method. In the static dispatch case there would be no cost in Dart 2 and in Dart2 it is ok if the dynamic dispatch case is more expensive. There would be some edge cases in the dynamic case that would be a bit off for anonymous js classes but the amount of odd behavior would be a lot more limited.

Back in a Dart 1.0 world this was also reasonable you could implement a Dart class with noSuchMethod that chose to use JS semantics for tearoffs so it isn't quite as far outside of the regular Dart behavior.

[jmesserly]

merging this into #35084. Agree with y'all that we should perform the tearoff, based on the static type info.