Incorrect type inference when using `call` in Records

[rrousselGit]

Consider the following:

final foo = (call: <T>(T value) => value,);
final value = foo<int>(42);

Currently, the type of value is inferred as dynamic. But this is incorrect.

Writing: final value = foo.call<int>(42) fixes the type-inference issue.

[lrhn]

That's a bug. You should not be able to call that record as a function at all.

The only non-function types which are "callable" are ones which expose a call method, either by declaring a call method itself, or by having an extension call method which applies.

A record with a call field is not a method, so this program should just refuse to compile, and say that the record type is not a function.

(Could be why typing goes wrong, if part of the compiler doesn't even think there is a call there.)

[rrousselGit]

:(

I liked that I could have a generic call:

typedef Callable<T extends Function> = (
  T call,
  <some other stuff>,
)

[lrhn]

And structurally typed too. Very nice. But not intended, and not specified. There is nothing in the records specification which should make them an exception to the general rule for when you can call an object like a function.

It seems the analyzer infers dynamic, probably because it doesn't know what to do.
The front-end actually infers the "correct" return type.

I'll close this issue, since we're not going to specify another (or any) return type, and defer to the bug for properly removing this "feature".