replace implicit 'any' with 'unknown'
See original GitHub issueSearch Terms
noImplicitAny, strict, any, unknown
Suggestion
When enabling "strict": true
or "noImplicitAny": true
in a project, could we assign unknown
to un-inferred/un-typed variables, instead of causing a compiler error? This would be a non-breaking change, since all cases where this would have an effect are already compiler errors.
Use Cases
It would allow avoiding having to specify a type when it’s being type-checked anyway. The current implementation forces converted-from-js projects to deal with a lot of compiler errors from the outset (many of which use various runtime type-checking methods so should be happy with implicit unknown
s).
Examples
const getMessage = input => typeof input === 'string' ? input : 'hello';
const shortenMessage = message => message.substring(3);
the getMessage
example would be an error currently, but would be fine in the new world and the function would have return type string
.
the shortenMessage
example would have a changed error. instead of Parameter 'message' implicitly has an 'any' type
we’d see an error at message.substring
of Object is of type 'unknown'.
To me that’s more intuitive in terms of what the problem actually is. message
is unknown so it should have type unknown
.
Checklist
My suggestion meets these guidelines:
- This wouldn’t be a breaking change in existing TypeScript / JavaScript code
- This wouldn’t change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn’t a runtime feature (e.g. new expression-level syntax)
Issue Analytics
- State:
- Created 5 years ago
- Reactions:52
- Comments:9 (5 by maintainers)
Top GitHub Comments
In principle this is true, but I suspect there’s a lot of code like this where this change would introduce a giant wall of new errors:
We could potentially have some
implicitUnknown
flag instead thoughI had a discussion recently where I realized it would be useful to replace any with unknown in situations like this, as it’s a much safer value to work with and mirrors some of the recent changes made to type inference in generics.
However, a potential flaw in this suggestion is that if a type isn’t checked in the same project, the author may forget to add a type that should be added explicitly when it instead returns unknown. For example, the user may be writing a library function that gets JSON from an API using
(await fetch(...)).json()
, which returnsPromise<any>
. This option would returnPromise<unknown>
instead of encouraging the user to explicitly add a type, which could cause type errors or unhelpful development experience from code using the library’s return type in TypeScript.As a result, it would be safer to add an
implicitUnknown
option that changes implicit type generation to useunknown
instead ofany
(similar to what generic parameters already do) so that TypeScript users have the option of keeping noImplicitAny on. I think this could even be a good option to turn on by default, if it could be done in a way that didn’t cause extra compatibility type errors.