Implicitly tear off `call` from receiver whose type is a type variable

[eernstg]

Thanks to @johnniwinther for noticing this. Consider the following program:

class A {
  void call() {}
}

Function f<X extends A>(X x) => x;

void main() {
  print(f(A()));
}

This program is rejected by the analyzer as well as the common front end (DartPad based on SDK 3.3.0-213.0.dev). However, the interface of a receiver of type X is the interface of the bound A, which implies that the interface of x does include a method named call, which means that we should be able to tear it off implicitly when the context type is Function or a function type.

The missing support for call is concerned with implicit tear-offs only, the implicit insertion of call that enables an invocation is working in the analyzer as well as the CFE.

[johnniwinther]

Should we also handle access of call on record types?

  var r = (call: () {},);
  Function f = r; // = r.call ?
  r(); // = r.call() ?

[eernstg]

I do not think we should support an implicit invocation of a call getter on a record type based on a context type mismatch: The corresponding situation with a receiver whose static type is a class that has a call getter is a compile-time error.

[johnniwinther]

So we still restrict this to finding a call method on the underlying interface? I can see the CFE doesn't allow the found call member to be a getter/field.

[eernstg]

method

Yes. It is highly likely that support for call method tear-off will be removed from the language in the future. However, the language team ended up keeping call method tear-offs for now, and even adding it for extension typed receivers in dart-lang/language#3467 (because it would be an odd exception if we hadn't done that).

On the other hand, there's no reason to start introducing support for statically resolved implicit call getter invocation—there is nothing else to be consistent with.

We do have a somewhat similar situation with dynamic calls where implicit call getter invocations do occur with the current implementations, but I still think we should stick to the specified behavior for the statically resolved case. This will also keep the situation at the same level of trade-offs in dart-lang/language#3482, rather than pushing the balance in any specific direction.

[srawlins]

I think both front-ends have landed a fix. OK to close, @eernstg ?

[eernstg]

Sounds good, thanks!