Spreading an extra `{}[]` to an array results in bad inference

[devanshj]

🔎 Search Terms

Spreading arrays, weak type unions

🕗 Version & Regression Information

Tested with v5.9.2

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/CYUwxgNghgTiAEEQBd5QFzwN7wGYHt8B+TAVwDsBrc-Ad3PgF8BtAXQChRJYElUAjTFhYc+8AB5C8hEvADOyGAEtyAcyZt4AXnjMAdAait48APSn4wfCDnkA5KjD4AtgAclSADTxVhYOzEATykCYkwFZTUNYx19Q28DPX5jc3gnNw8bb34oYCA

💻 Code

declare let a: { foo?: unknown }[]
declare let b: {}[]
let x: { foo?: string }[] = [...a]  // doesn't compile, good
let y: { foo?: string }[] = [...a, ...b] // compiles, bad

🙁 Actual behavior

The declaration y type-checks

🙂 Expected behavior

The declaration y should not type-check.

Additional information about the issue

No response

[Andarist]

What type do you expect to get from this operation?

const result = [...a, ...b];
//        ^?

At the moment, this is {}[] and it makes sense given it finds a common supertype among spread element types. And that is assignable to { foo?: string }[].

[devanshj]

The type of result should be ({ foo?: unknown } | {})[]. This is basically how it works in other cases too...

declare let a: { bar: string }[]
declare let b: { baz: number }[]
let result = [...a, ...b]
//  ^? ({ bar: string } | { baz: number })[]

Reducing { foo?: unknown } | {} to {} is unsound.

Here's an example that compiles but gives runtime error (ie is unsound)...

const f = (xs: { foo?: string }[]) => {
  xs.forEach(x => console.log(x.foo?.toLowerCase()))
}
let a: { foo?: unknown }[] = [{ foo: 1 }]
let b: {}[] = [{}]
let x = [...a, ...b]
f(x)

[krryan]

It’s actually got nothing to do with {}[] or {} at all, it’s all about the optional property. This behaves the same way:

const f = (xs: { foo?: string; bar: number }[]) => {
  xs.forEach(x => console.log(x.foo?.toLowerCase()))
}
let a: { foo?: unknown; bar: number }[] = [{ foo: 1, bar: 2 }]
let b: { bar: number }[] = [{ bar: 3 }]
let x = [...a, ...b]
f(x)

See in playground. x is treated as { bar: number }[].

Whether or not that is a bug, though, I don’t know. You can see why it’s doing what it’s doing—the type without the optional property is the common denominator here, which you ordinarily want—but obviously in this case it’s unsound. But perfect soundness is not a goal for TS. That’s going to be a judgment call on whether that catches enough bugs vs. causes more problems from other use-cases that want it to be treated as the common denominator.

[MartinJohns]

The magic keyword here is "subtype reduction". See also: Best common type

[RyanCavanaugh]

"fixing" this just creates a different bug where these are inconsistent:

declare let a: { foo?: number }[]
declare let b: {}[]
let x: { foo?: string }[] = [...a]  // doesn't compile, good

let z = [...a, ...b];
// z: {}[]
let y: { foo?: string }[] = z; // ok, not consistent

Reducing { foo?: unknown } | {} to {} is unsound.

I disagree. The unsoundness comes from the fact that {} is assignable to { foo?: unknown }, not the reduction.

Without exact types there's not really a consistent fix available here, since you need the ability to prove that there's not a foo key with an out-of-type value in it in order to assign to the optional property.

[devanshj]

{} is assignable to { foo?: unknown }

Oh I didn't realise this. Yeah this is the part that causes unsoundness.

Without exact types there's not really a consistent fix available here, since you need the ability to prove that there's not a foo key with an out-of-type value in it in order to assign to the optional property.

Yeah... (Just crosslinking in that case - #12936)