Adding a tsconfig option to disallow implicit never and unknown

[Klopfsalat]

🔍 Search Terms

"never", "unknown", "tsconfig", "implicit"

✅ Viability Checklist

• 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. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

never and unknown unlike any dont have a tsconfig.json option.
My suggestion is to add an option to the file similar to any.
To avoid problems i would suggest to set it as false and to later on add it with true to the strict mode in later versions to give people time to adjust.
tsconfig options could look like the following:

{
    "compilerOptions": {
        ...
        "noImplicitUnkown": false,
        "noImplicitNever": false,
        ...
    },
    ...
}

📃 Motivating Example

It would lead to cleaner coding and less problems when strict mode is on.

💻 Use Cases

Q: What do you want to use this for?
A: To easily get the compiler to show me when there are variables that have unintended never/unknown as datatype.

Q. What shortcomings exist with current approaches?
A: People create variables that get read as never/unknown by the compiler and when others try to clean it up later they have a harder time understanding what the intended value should be. It leads to worse code.

Q: What workarounds are you using in the meantime?
A: Using Eslint.

[fatcerberus]

I’m confused — there isn’t a such thing as an “implicit” unknown or never in the same sense that noImplicitAny is meant to guard against. Can you give an example of some code that you think these flags should error on? (that’s what the Motivating Example section is for, btw)

[RyanCavanaugh]

I don't know what an "implicit unknown" or "implicit never" are either. Code examples when describing suggestions for a programming language are very helpful.

[Klopfsalat]

with never it's a problem that probably only occurs when you try to change a project that wasn't on strict to a strict project. But i saw several occurrences of it and found it weird that its not getting marked like implicit any:

import { useState } from "react"
const [items , setItems] = useState([]);

Btw this obviously not pretty but doesn't create error telling me that there is an array created of type never. I would like this to get only approved by the compiler when i for some reason type the following:

import { useState } from "react"
const [items , setItems] = useState<never[]>([]);

[Klopfsalat]

i was wrong with unknown though, i dont think there is an example, overestimated the way noImplicitAny guards against any

[RyanCavanaugh]

I'm not understanding the motivation here.

If you create a never[], as shown here:

• If you read from it, it's correctly never (or never | undefined under NUIA)
• You can't write to it, so any mistakes are caught

Whereas with noImplicitAny, any[] is very dangerous:

• All reads produce any, which is dangerous
• All writes are allowed, which is arguably dangerous

When people wanted noImplicitAny there were many examples of coding errors that wouldn't otherwise get caught without it. What are the corresponding examples here?

[rotu]

The never[] issue had been brought up recently (#57419 for background).

If you create a never[], as shown here:

• If you read from it, it's correctly never (or never | undefined under NUIA)
• You can't write to it, so any mistakes are caught

I still don't think it's safe:

• A read from it is never which is (perhaps unsafely) assignable to anything (assuming NUIA is off).
• A write to it can be completely unchecked. I wrote it up here never assignability check disappears for method call from generic function #57453

const obj = { a: [] }
const pushA = <T,>(blah: {a: T[]}, a:T)=>{
    blah.a.push(a)
}
pushA(obj, 4)
pushA(obj, "foo")
// obj.a is now an array containing [4, 'foo'] but typed as never[]