Skip to content
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

support universal function types #27333

Closed
3 tasks done
jmesserly opened this issue Sep 13, 2016 · 2 comments
Closed
3 tasks done

support universal function types #27333

jmesserly opened this issue Sep 13, 2016 · 2 comments
Labels
P2 A bug or feature request we're likely to work on web-dev-compiler

Comments

@jmesserly
Copy link

jmesserly commented Sep 13, 2016

From @jmesserly on April 25, 2016 22:15

Initial implementation of #301 may not cover this.

  • ensure these have a runtime representation (likely done as part of support for file I/O #301)
  • implement subtyping rules
  • prevent these types from being treated as callable functions (e.g. (f.runtimeType as dynamic)(int) where f is a generic function). Discussed at the end.

These can't be written down yet, but they can come up in inference, for example:

/*=T*/ f/*<T>*/(/*=T*/x) => x;
main() {
  var y = f;
  y = /*<S>*/(y) => y; // legal
}

Note the generic function expression is #527

I'm not aware of this blocking anything, but for consistentcy with Analyzer we should support it.

Regarding "prevent these types from being treated as callable functions": we may need to split out into its own bug, as it likely requires changing how generic classes look. Generic class types & function typedefs are callable, which was okay because they weren't accessible as first-class values. But universal function types can be gotten from .runtimeType, and will likely have a literal form as well: MyGenericFnType. It's not a huge problem if that value is "dynamically callable", since the Type interface does not say anything about supporting call, but it seems suboptimal.

Copied from original issue: dart-archive/dev_compiler#526

@jmesserly
Copy link
Author

This is now fixed!

@jmesserly
Copy link
Author

The reason these types aren't callable is because we fixed this issue in general by returning user-visible Types that wrap our internal types, preventing implementation details from leaking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 A bug or feature request we're likely to work on web-dev-compiler
Projects
None yet
Development

No branches or pull requests

1 participant