replace implicit 'any' with 'unknown'

[mmkal]

Search 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 unknowns).

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)

[RyanCavanaugh]

This would be a non-breaking change, since all cases where this would have an effect are already compiler errors.

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:

// @ts-ignore
function fn(x, y, a, b, c, d) {
  // do tons of stuff with x y a b c and d
}

We could potentially have some implicitUnknown flag instead though

[ghost]

My 2 cents:

• If I saw function f(x) {} in the wild, I would assume that noImplicitAny isn't set. I would be surprised to discover that the type of a variable changed due to a change in compiler options -- as far as I know no other programming language works that way. When you factor in conditional types this means that something that's a string with one set of compiler options could be a number under different settings.

type F<T> = string extends (T extends {} ? string : boolean) ? string : number;
// Currently returns string; if `x: unknown`, returns number
function f(x): F<typeof x> {
    return <any>null;
}

• It's rare for a function to really work for any arbitrary input. We would probably be right more often if we assumed that unannotated variables are strings, not that I recommend that. It's more likely that the type annotation was forgotten by mistake, especially if the user mistakenly assumed that they had a contextual type.
• When you forget a type annotation, it's better to have the error message at the place where the type annotation should go, rather than getting errors at each use of that variable and taking some time to realize the root cause.

[mmkal]

@RyanCavanaugh - good point, that case would break, so it probably would make sense to put this behind a flag if it were implemented.

@andy-ms - isn't strictNullChecks a compiler option which can change types by being on?

It's true that it's rare for a function to work for any input at all, but not that strange for it to be able to take many different forms, and do type checking (typeof/io-ts etc.) in the implementation. noImplicitAny solves this problem but in a way that is both restrictive and potentially dangerous. Because the annotation is the only place the error appears, all other code using the un-annotated parameter compiles without problems, which makes it more likely that the code will make bad assumptions (e.g. not null-checking an optional property), and actually force the developer to eventually type it as any to make all the errors go away, which is a shame IMO.

If unknown had been around since the beginning of typescript, I suspect this is how it'd work. There would be no compiler option(s) for it, un-annotated parameters would just be unknown, because it's a fitting description!

[ExE-Boss]

@mmkal

isn't strictNullChecks a compiler option which can change types by being on?

Yes, yes it is (without it, T|null behaves like T, whereas with it, it actually behaves like T | null)

It's true that it's rare for a function to work for any input at all, but not that strange for it to be able to take many different forms, and do type checking (typeof/io-ts etc.) in the implementation. noImplicitAny solves this problem but in a way that is both restrictive and potentially dangerous. Because the annotation is the only place the error appears, all other code using the un-annotated parameter compiles without problems, which makes it more likely that the code will make bad assumptions (e.g. not null-checking an optional property), and actually force the developer to eventually type it as any to make all the errors go away, which is a shame IMO.

Yeah, it is.

If unknown had been around since the beginning of typescript, I suspect this is how it'd work. There would be no compiler option(s) for it, un-annotated parameters would just be unknown, because it's a fitting description!

This is how Eclipse N4JS behaves.

[ExE-Boss]

Also, it might be a good idea to have implicitUnknown override noImplicitAny and have .d.ts files with unknown where any would have been generated before.

[ExE-Boss]

I’ve done some prototyping work on this in #30813.

[nickserv]

I 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 returns Promise<any>. This option would return Promise<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 use unknown instead of any (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.

[n9]

Will this also handle arrays?

function foo(input: {}) {
  if (input instanceof Array) {
    // `input` is currently `any[]` instead of `unknown[]`
    if (input.length > 0) {
      console.log(input[0].anyProp);
    }
  } else if (...) {
    ...
  }
}

And what is the current best practice workaround to force unknown[]?

[mmkal]

Will this also handle arrays?

I think it should, and in general it should work for generics:

class MyClass<T> {
  constructor(readonly value: T) {}
}

function foo(input: {}) {
  if (input instanceof MyClass) {
    // input is MyClass<any> now, should be MyClass<unknown>
    console.log(input.value.thisPropertyProbablyDoesNotExist())
  }
}

@nickmccurdy I don't know if this rule existed in September 2019 when you wrote your comment, but no-unsafe-return could help with that scenario. But sure, for backwards-compatibility I guess the noImplicitAny flag would need to stay functional, even though it's kinda more of a linter responsibility. Three years on, I like the idea of having implicitUnknown as a separate flag - it just-so-happens to make noImplicitAny a really easy requirement to fulfill.

[miguel-leon]

I would like to write:

type x = keyof { a, b, c, d, e, f };
// instead of
type y = 'a' | 'b' | 'c' | 'd' | 'e' | 'f';

it's shorter and easier to write.

But it errors with noImplicitAny. The suggestion in this thread could make that possible (?)... the compiler can't tell that the property types are not really being used and that the "implicit" any is immediately discarded right?