`T[] | { t: 'a' } & { t: 'b' }` is not iterable (TS2488)

[satgo1546]

🔎 Search Terms

TS2488

🕗 Version & Regression Information

• This changed between versions 3.8.3 and 3.9.7 (tested with the playground)
• I was unable to test this with every-ts because this issue seems to affect only the editor, not tsc

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=3.9.7#code/CYUwxgNghgTiAEA3W8AeAueA7ArgWwCMQYBtAXXgB94BveAF0wHIon4BfeAMloeYLbsAUBBD14JEKLwUAvGiA

💻 Code

declare var x: number[] | { t: 'a' } & { t: 'b' }
let [elem] = x

🙁 Actual behavior

The array destructure fails with this error:

Type 'number[]' must have a '[Symbol.iterator]()' method that returns an iterator.(2488)

🙂 Expected behavior

No error should be present.

Since an object cannot have a field t that holds both 'a' and 'b', { t: 'a' } & { t: 'b' } reduces to never. And number[] | never decays to number[], which is iterable by definition.

Additional information about the issue

No response

[MartinJohns]

I mean.. having an error is correct. Your type is not iterable. You're not always having an array, you're also having a { t: 'a' } & { t: 'b' }

But the error message should mention the other type.

[urvil5256]

Hi,

As per your typescript code we can not able to assign multiple type values at same time either you assign Array type or an Object type but you can't assign both because of that the issue came.

So, to use such things you can use it like below different ways.

1. Here you can assign either number[] or { t: 'a' } or { t: 'b' } or [{ t: 'a' } & { t: 'b' }] then it will work.

declare var x: number[] | { t: 'a' } | { t: 'b' }; // Then check if x is array before destructuring if (Array.isArray(x)) { let [elem] = x; }

2. Also, you can assign value to [elem] like: let [elem] = x as number[];

Using both the way the error has been resolved.

Let me know which approach will feasible for you.

Thank you

[nmain]

'a' & 'b' is never so the second union constituent decays to never, and number[] | never decays to number[]. The language server even shows the type as just number[]:

type Foo = number[] | { t: 'a' } & { t: 'b' }
//   ^ number[]

I'm not sure this is a bug, but there's some justification for the result to be iterable at least.

[satgo1546]

'a' & 'b' is never so the second union constituent decays to never, and number[] | never decays to number[].

Yeah, that's also my reasoning behind the bug report. I've edited the issue description to include it for clarity.

[jcalz]

(not a TS team member, feel free to ignore me)

I expect the issue here is that getReducedType() (as introduced in #36696) doesn't get called before accessing the Symbol.iterator method. They could maybe change that but I thought getReducedType() has sometimes been responsible for compiler performance problems (lots of extra work, circularities leading to crashes, etc)? If so, not sure it's worth it.

[RyanCavanaugh]

It's legitimately confusing that the error describes a situation that is not true.

In TS 7 the improved type-ordering logic causes a more-correct error to be printed, though possibly you could construct a repo where you still see the bad version of the error

a.ts:2:5 - error TS2488: Type 'never' must have a '[Symbol.iterator]()' method that returns an iterator.

2 let [elem] = x
      ~~~~~~

If there is an extremely minimal fix here we could look at it for the JS codebase but it doesn't seem like a big priority

[jcalz]

Why is the problem with the wording of the error message? X | never has all the members that X has, since never is a subtype of X for all X. I mean, the prohibition on indexing into never is more of a linter thing than a safety thing, right? Stopping people from indexing into a pure never makes sense, but stopping them from indexing into a union with never is... well, it seems bonkers to me. The only reason this is showing up at all is because the reduction to number[] is happening too late to avoid the error, but apparently early enough when displaying the type.

So the "more-correct" error talking about never is misleading. Nobody's trying to index into never here. I'd say if there's a fix here it isn't to change the wording of the error, but to remove the error. Or if the wording is changed, it should be to something like error TS252525: This concept of 'number[] | ({ t: 'a' } & { t: 'b' })' confuses and infuriates us!

[RyanCavanaugh]

Trying to remove the error entirely will absolutely introduce new circularity errors in existing codebases. I don't really want to spend breaking change points on addressing a situation that doesn't make sense to be in in the first place.

[satgo1546]

a situation that doesn't make sense to be in in the first place

The code in the issue description is a minimal working example. FYI, I actually encountered this error in a pretty reasonable setting, I think. Here's the gist:

A third-party package exports a discriminated union type. Let's call it Shape.

export type Shape =
  | { kind: 'circle', radius: number }
  | { kind: 'rectangle', width: number, height: number }

And I have a function that deals only with a circle. It accepts either a plain circle object or a React-style [value, setValue] pair. I have to extract the circle type out of the discriminated union through an intersection, which internally introduces { kind: 'rectangle', … } & { kind: 'circle' }. Now the pair cannot be destructured due to type Circle not cleanly reduced.

import { type Shape } from 'some-package'

type Circle = Shape & { kind: 'circle' }

function doStuffWithCircle(arg: Circle | [Circle, (newValue: Circle) => void]) {
  if (Array.isArray(arg)) {
    let [value, setValue] = arg
    // error: Type '[{ kind: "circle"; radius: number; } & { kind: "circle"; }, (newValue: { kind: "circle"; radius: number; } & { kind: "circle"; }) => void]' must have a '[Symbol.iterator]()' method that returns an iterator. (ts2488)
  }
}

[Andarist]

The above is interesting.

1. When the arg gets narrowed by getNarrowedTypeWorker (called by narrowTypeByTypePredicate) it still contains that "reduced never" ({ kind: "rectangle"; width: number; height: number; } & { kind: "circle"; }) that isn't displayed in type hovers given it's "never" that shouldn't appear in unions.
2. and then the filtering logic there doesn't "reject" it because isTypeStrictSubtypeOf(t /* reduced never */, c /* any[] */) // true, so it's kept in the output/narrowed type
3. that leads to the originally reported situation, given the getIterationTypesOfIterable isn't equipped to deal with those reduced nevers either