Type hole: everything is assignable to element of generic indexable

[awerlogus]

Bug Report

🔎 Search Terms

generic tuple element assignable

⏯ Playground Link

Playground link with relevant code

💻 Code

// No error, but expected
const a = <T extends [unknown]>(x: T): T[0] => 123

// string type, but number value
const b = a([''])

🙁 Actual behavior

It's possible to return everything

🙂 Expected behavior

It's possible to return entities which only have T[0] type

[fatcerberus]

Hmm, it seems like TS is eagerly reducing T[0] to unknown here. Not sure whether that’s intentional or not.

[typeholes]

Oddly, this does error:
const a = <U extends unknown, T extends [U]>(x: T): T[0] => 123

[fatcerberus]

@typeholes Username checks out

[Andarist]

Essentially the problem is the same as the one here:

// No error, but expected
const a = <T extends { foo: number | string }>(x: T): T["foo"] => 123

// string type, but number value
const b = a({ foo: 'str' })

In other words, it's not limited to tuples. It's actually about indexed accesses with non-generic index constraints that are concrete~ (index signatures are not prone to this) on generic objects. The code responsible for this is here

[awerlogus]

Probably related #45335

[fatcerberus]

This may be trickier than it first appears. Clearly we can tell that

// Exhibit A
const a = <T extends { foo: number | string }>(x: T): T["foo"] => 123

is unsound and should be an error. But what about this variant?

// Exhibit B
const b = <T extends { foo: number | string }>(x: T): T["foo"] => x["foo"]

It's already established that returning a string | number here is not sound and should be an error. But this particular case is completely safe, and there's almost certainly code in the wild that relies on it not being an error. HOWEVER, then there's this one...

// Exhibit C
const c = <T extends { foo: number | string }, U extends { foo: number | string }>(x: T, y: U): T["foo"] => y["foo"]

...which is again unsound (U could be wider than T). But if you're only looking at the constraints, which is what TS appears to be doing, this case C looks identical to case B above. What to do, what to do...

[RyanCavanaugh]

Clearly the only sound behavior in this case is to only allow expressions that are exactly of the form x[0], but x[0] doesn't have the type T[0], it has the type from the constraint. It's not clear there's anything we could do to improve the situation here except to radically rework how indexed access works in generic functions, which I don't think is quite on the table yet given the motivating scenarios apart from this one

[mkantor]

I found this issue after coming across code like this:

const test = <T extends { a: unknown }>(x: T) => { x.a = 123 }
const x = { a: '' }
test(x)
const notString = x.a
//    ^? const notString: string

I think that's a symptom of the same underlying problem.

EDIT: Or not, because this also (unsurprisingly) has the same issue. I guess writing to properties of inputs is just inherently unsafe.

[awerlogus]

@mkantor You may be looking for #39915