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

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

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

Comments

@jmesserly
Copy link
Contributor

@jmesserly jmesserly commented Jan 25, 2016

@jmesserly

This comment has been minimized.

Copy link
Contributor Author

@jmesserly jmesserly commented Jun 11, 2016

Taking a look at this.

@jmesserly

This comment has been minimized.

Copy link
Contributor Author

@jmesserly jmesserly commented Jun 21, 2016

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

@jmesserly

This comment has been minimized.

Copy link
Contributor Author

@jmesserly jmesserly commented Jun 23, 2016

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

This comment has been minimized.

Copy link
Contributor Author

@jmesserly jmesserly commented Jun 27, 2016

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

  • no-implicit-dynamic: roughly what the CL does.
  • no-implicit-casts: mostly implemented, see #26583
  • no-inferred-dynamic: any position where a type could be inferred, report if inference fails. Inference here includes downward inference and variable initialization, TBD other cases like [42 as dynamic], see #26781
  • no-implicit-generic-types: disallow using C to stand for C<dynamic>. TBD if C means C<Object> or is an error, see #26784

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

This comment has been minimized.

Copy link
Contributor Author

@jmesserly jmesserly commented Jun 27, 2016

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
Projects
None yet
2 participants
You can’t perform that action at this time.