Empty array ([]) inferred to be never[] instead of [] or undefined[]

[maranomynet]

Bug Report

I ran into this behavior where TypeScript infers that an empty array (literal []) to be of type never[], which it interprets to never happen and thus to be of no sigificance.

Runtime errors then ensue.

🔎 Search Terms

"never[]" array

🕗 Version & Regression Information

Affects all versions from 3.5.1 through 4.9.4 (and the nightly)

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about "common-bugs-that-arent-bugs"

⏯ Playground Link

Playground link with relevant code

💻 Code

const ret = Math.random() > 0.5 ? ['foo', 'bar'] as const : [];
//    ^? const ret: readonly ['foo', 'bar'] | never[]

// @ts-expect-error  (because `ret[0]` may be `undefined`)
const foo: string = ret[0]
//                      ^? (property) 0: "foo"
// @ts-expect-error  (because `ret[1]` may be `undefined`)
const bar: string = ret[1]
//                      ^? (property) 1: "bar"

// 🔥🔥 This will throw a runtime error half the time. 🙀
console.log(
    foo.toUpperCase(),
    bar.toLocaleLowerCase()
)

🙁 Actual behavior

I get a TS error on the @ts-expect-error comment as the ret tuple is inferred to be effectively always ['foo', 'bar']

...and then I get runtime errors once I try and do .toUpperCase() on the (sometimes undefined) values.

🙂 Expected behavior

I'd expect the inferred type of ret to be something like readonly ['foo', 'bar'] | [] or possibly readonly ['foo', 'bar'] | | Array<undefined>.

To fix this I have to explicitly change the first line to either:

const ret = Math.random() > 0.5 ? ['foo', 'bar'] as const : [] as [];

…or:

const ret = Math.random() > 0.5 ? ['foo', 'bar'] as const : [] as const;

[fatcerberus]

Working as intended. In this context never[] doesn’t mean “never happens” but rather indicates that the array contains only values of type never (which is trivially true—it’s empty).

The never[] typing for empty arrays is inconvenient, but is intentional because the alternatives are worse. See #51853 (comment)

[tylim88]

I am more concerned about array being any[]

const a = false || []
//    ^?
const b = []
//    ^?

[fatcerberus]

@tylim88 It’s not really any[]. It’s an evolving type, so if you .push() something into it, the compiler will infer the type of whatever value(s) you add.

[tylim88]

@fatcerberus

I see, thx for your explanation

before evolve:

after evolve:

[maranomynet]

The JS code is obviously buggy, the conditional assignment to res is pretty straightforward, yet TypeScript fails to capture this and somehow this is fine?

Can anyone please help me understand why the runtime error is not a problem?

In fact, even a type of readonly ['foo', 'bar'] | any[] would seem to be more correct (and useful).

[fatcerberus]

That's completely unrelated to the never[] inference, though. The runtime error still happens even if the inferred type is any[], because there's no bounds checking for array accesses, only for tuple types. You might want to consider enabling noUncheckedIndexedAccess if that's a problem for you.

const ret = Math.random() > 0.5 ? ['foo', 'bar'] as const : [] as any[];
//    ^? const ret: any[] | readonly ['foo', 'bar']

const foo: string = ret[0]
const bar: string = ret[1]

// STILL throws a runtime error half the time.
console.log(
    foo.toUpperCase(),
    bar.toLocaleLowerCase()
)

[maranomynet]

In fact noUncheckedIndexedAccess makes no difference here, as the inferred type is to be effectively just readonly ['foo', 'bar']. Which is my point.

Not that I'm actively rooting for any but then the untrustworthyness of values pulled out of ret are at least somewhat more apparent

Playground link

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.