Cannot use matching indexes across objects with similar types

[ftrimble]

TypeScript Version: Reproduced in the playground - i assume this is running latest. before running in the playground was running on 3.4.5

Search Terms:
keys across objects cannot be compared
type values at same indexes do not honor that keys can only assume one value at a time

(I'm having a hard time describing this issue, so I may have failed to search for it effectively; forgive me if that's the case.)

Code

type A = { a: 'a' | 'b'; b: 'c' | 'd'; };
type B = { a: ('a' | 'b')[]; b: ('c' | 'd')[]; };
type C = { a: string; b: number };
type D = { a: string[]; b: number[]; }


const a: A = { a: 'a', b: 'c' };
const b: B = { a: [], b: [] };
const c: C = { a: 'asdf', b: 1234 };
const d: D = { a: [], b: [] };

(['a', 'b'] as const).forEach(key => {
    b[key].push(a[key]);
    b[key] = [...b[key], a[key]];
    d[key].push(c[key]);
    d[key] = [...d[key], c[key]];
});

Expected behavior:

All of the options for adding the keys to the array in the second half of the example above should compile and work correctly.

Actual behavior:

The LHS of the equation is considered an & type while the RHS is an | type, which makes them incompatible. These types are clearly correct and should work, but e.g. b[key] is consider a never for the purposes of push ('a' | 'b' & 'c' |'d'), while d[key] is considered a string & number for those purposes (not sure why this isn't also a never)

The important part of this issue is that none of the possible ways of using these types together compile. All possible variants create too strict of a typing for what needs to go into the array variant of the original type, even though the types of the objects at identical keys are compatible

Playground Link:

playground link

Related Issues:

[RyanCavanaugh]

These errors are correct from the type system's perspective because there's no mechanism that correlates that both utterings of key must be the exact same value - they simply have the same type, which is not a sufficient proof that i.e. b[k1].push(a[k2]) is a valid call because k1 could be "a" and k2 could be "b"

The "expanded" form checks as expected:

(['a', 'b'] as const).forEach(key => {
    if (key === 'a') {
        b[key].push(a[key]);
        b[key] = [...b[key], a[key]];
        d[key].push(c[key]);
        d[key] = [...d[key], c[key]];
    } else if (key === 'b') {
        b[key].push(a[key]);
        b[key] = [...b[key], a[key]];
        d[key].push(c[key]);
        d[key] = [...d[key], c[key]];
    }
});

If you imagine the compiler expanding out all code bodies to be an individually-rechecked block that iterates over all possible combinations of union values it closes over, then it'd be possible to check this function as expected, but you can also see why that kind of implementation would be thousands of times slower for any nontrivial block.

[ftrimble]

I'm somewhat skeptical that this needs to be "thousands of times slower". The important part here is that there is no k2 as argued in your example above:

b[k1].push(a[k2]) is a valid call because k1 could be "a" and k2 could be "b"

This is only operation on k1 and it is not possible that k1 can be both a and b simultaneously - it must be one or the other.

Maybe your point is that

there's no mechanism that correlates that both utterings of key must be the exact same value

But i would argue that's a solvable problem - it is inferrable from the source that key has not changed between invocations, which is precisely why i filed this ticket.

It's hard for me to accept that writing the same block of code for every possible value here is the typescript supported way of doing this... especially when you would have to actually write out every line many times given that this cannot be written as a function or the same issue arises.

[RyanCavanaugh]

It's hard for me to accept that writing the same block of code for every possible value here is the typescript supported way of doing this

It's not, it was just a demonstration of the fact that the checker can reason about the code in the case where the type is known to be exactly one value.

But i would argue that's a solvable problem

Certainly possible, yes, just a massively complex undertaking we're not inclined to tackle at this point.

[fatcerberus]

In other words, the compiler sees at each line “object indexed with key of type 'a' | 'b'” and that’s all the data it has—it doesn’t even have enough information to be able to say “oh, it’s the same variable as last time” (this information simply isn’t tracked). It’s true that TypeScript can narrow types based on conditional statements, but that’s done by a completely a separate mechanism if my understanding is correct.

[fatcerberus]

Thinking about this some more, it’s kind of interesting. I’m not convinced it would be enough just for TS to know key is the same value each time; the concrete problem here is that key is type "a" | "b" and therefore we don’t actually know at compile-time what type the indexing operation is going to return.. So TS would need to, besides realizing that key is always the same value, also be able to do a type relation between two unknown types—which to me sounds very challenging.

As human beings, we know if the key is the same, so will the type retrieved, regardless of what types are involved, but this doesn’t automatically follow from the compiler’s perspective unless the compiler is explicitly programmed to track it.