`null` gets accidentally eliminated when narrowing by undefined's equality about typescript HOT 8 CLOSED

I can see that but it also means that the P[K] & {} being assignable to S[K] (something that is allowed today) is already speculative too, right?

Well, it's allowed only because of the oddity of Record<string, any> constraints (see my comment).

from typescript.

Simpler repro:

function f1<T extends Record<string, any>, K extends keyof T>(x: T[K] | undefined) {
    if (x === undefined) return;
    x;  // T[K] & ({} | null)
    if (x === undefined) return;
    x;  // T[K] & {}
}

from typescript.

In addition to the odd narrowing behavior demonstrated by the OP and the simplified repro above, we also have inconsistencies in type relationships involving intersections that strip undefined, null, or both:

function f2<T, K extends keyof T>(t: T[K], p1: Partial<T>[K] & {}, p2: Partial<T>[K] & ({} | null)) {
    t = p1;
    t = p2;  // Unexpected error
}

The issue here is missing normalization of intersections in certain cases. Specifically, we only normalize intersections with {}, not intersections with null or undefined.

from typescript.

@ahejlsberg that feels like an answer to this comment, right? I mean, this extra observed problem would fix what has been described there.

Do you plan to work on fixing this? Or should I try to extend my PR with a fix for this?

from typescript.

Furthermore, using Record<string, any> as a constraint exhibits some odd behavior:

function f3<T, P extends Record<string, any>>(t: T[keyof T], p1: P[keyof P], p2: P[keyof P] & {}) {
    t = p1;  // Error as expected
    t = p2;  // Missing error
}

function f4<T, P extends Record<string, unknown>>(t: T[keyof T], p1: P[keyof P], p2: P[keyof P] & {}) {
    t = p1;  // Error as expected
    t = p2;  // Error as expected
}

This has to do with the constraint of P[keyof P] being any which effectively circumvents type checking in some cases. In general, it seems suspicious for any instantiable type to have a constraint of any, and we do indeed ignore such constraints in places. Just not everywhere.

from typescript.

@ahejlsberg that feels like an answer to #57692 (comment), right? I mean, this extra observed problem would fix what has been described there.

Given type parameters S and K extends keyof S, I would expect Partial<S>[K] & ({} | null) to be assignable to S[K]. However, when P extends Partial<S>, I think expecting P[K] & ({} | null) to be assignable to S[K] is getting speculative.

Do you plan to work on fixing this? Or should I try to extend my PR with a fix for this?

I will be putting up a PR that fixes the issues demonstrated by f1 and f2 above.

from typescript.

However, when P extends Partial<S>, I think expecting P[K] & ({} | null) to be assignable to S[K] is getting speculative.

I can see that but it also means that the P[K] & {} being assignable to S[K] (something that is allowed today) is already speculative too, right?

from typescript.

It has been called an oddity but I'm not sure if I should interpret this as "odd but working as intended" or "odd and it could be fixed" 😅 In general, I interpret your comments about this here as the latter but I'm not 100% sure.

from typescript.