Skip to content

Incorrect type inference when using call in Records #3558

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rrousselGit opened this issue Jan 13, 2024 · 3 comments
Closed

Incorrect type inference when using call in Records #3558

rrousselGit opened this issue Jan 13, 2024 · 3 comments
Labels
feature Proposed language feature that solves one or more problems

Comments

@rrousselGit
Copy link

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.

Screenshot 2024-01-13 at 19 04 01

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

Screenshot 2024-01-13 at 19 04 16
@rrousselGit rrousselGit added the feature Proposed language feature that solves one or more problems label Jan 13, 2024
@lrhn
Copy link
Member

lrhn commented Jan 13, 2024

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
Copy link
Author

:(

I liked that I could have a generic call:

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

@lrhn
Copy link
Member

lrhn commented Jan 13, 2024

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".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Proposed language feature that solves one or more problems
Projects
None yet
Development

No branches or pull requests

2 participants