Skip to content

Add --no-implicit-dynamic flag to strong mode #25573

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
jmesserly opened this issue Jan 25, 2016 · 5 comments
Closed

Add --no-implicit-dynamic flag to strong mode #25573

jmesserly opened this issue Jan 25, 2016 · 5 comments
Assignees
Labels
legacy-area-analyzer Use area-devexp instead. P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug

Comments

@jmesserly
Copy link

forked from #24267, also see: dart-archive/dev_compiler#299, dart-archive/dev_compiler#363, dart-archive/dev_compiler#365

@jmesserly
Copy link
Author

Taking a look at this.

@jmesserly
Copy link
Author

Note this will include implicit dynamic in a type argument to a class/typedef/generic function/generic method.

@jmesserly
Copy link
Author

implemented in https://codereview.chromium.org/2093523002/. I sent to @leafpetersen to see if the design seems right. There's a lot more nuance than I'd thought at first. In particular, how to handle implicit generic types used as type annotations. But there are some other interesting cases too, like the return type of a function expression.

@jmesserly
Copy link
Author

jmesserly commented Jun 27, 2016

So what we're brainstorming now is a set of flags as we gather data:

No current plans to implement these, but for completeness, here are some other ideas that have floated around:

  • no-reified-dynamic: fairly similar to no-implicit-dynamic, but would also reject explicit dynamic in reified positions (type arguments). TBD if this uses implicit-Object. Benefit unclear in a strong mode world (Object and dynamic are practically the same at runtime in strong mode).
  • no-dynamic: disallows dynamic entirely in the Analyzed code. TBD if this uses implicit-Object. The goal would be to guarantee no nSMs in the analyzed code.
  • implicit-object: use Object for missing types.

@jmesserly
Copy link
Author

CC @leafpetersen @munificent -- see above for my notes on the various flags we may want.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
legacy-area-analyzer Use area-devexp instead. P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

2 participants