Non-null assertion doesn't work for mapped types

[bowenni]

TypeScript Version:
Reproducible in 2.7.2 and 2.9.0-dev.20180502.
Irreproducible in 2.6.2

Search Terms:
Mapped types, Non-null assertion

Code

function f<A extends string>(p0: {[key in A]: {}|undefined}, p1: A) {
  const v: {} = p0[p1]!;
}

Expected behavior:
No errors.

Actual behavior:
In 2.7.2:
error TS2322: Type '{ [key in A]: {} | undefined; }[A]' is not assignable to type '{}'.
Type '{} | undefined' is not assignable to type '{}'.
Type 'undefined' is not assignable to type '{}'.

In 2.9.0-dev.20180502:
error TS2322: Type 'NonNullable<{ [key in A]: {} | undefined; }[A]>' is not assignable to type '{}'.
Type '{} | undefined' is not assignable to type '{}'.
Type 'undefined' is not assignable to type '{}'.

Playground Link:
I cannot reproduce the error in the playground.
From command line, I'm running node_modules/.bin/tsc -strict test.ts to reproduce it.

Related Issues:
#19608

Rado Kirov (@rkirov)

[mhegazy]

Wesley Wigham (@weswigham) can you take a look.

[weswigham]

I'm going to guess that when we look at NonNullable<{ [key in A]: {} | undefined; }[A]> and instantiate with the constraint and simplify to NonNullable<{} | undefined>, the process through which we do so is not creating a distributive conditional type (the original conditional was not distributed, and {} | undefined doesn't extend undefined, so just passes thru unchanged).

[bowenni]

Another question is why this is irreproducible in the playground?

[weswigham]

Bowen Ni (@bowenni) because as it turns out, this is a regression introduced by #23592, I believe (since, looking at the playground, it clearly worked in 2.8).

Update: Our conditional type constraint comparison logic was incorrect, but not for the stated reason. The distributivity is handled correctly, but how we got the constraint for an indexed access is off. We saw {[K in A]: {} | undefined}[string] and just...decided not to simplify it and return no constraint because the object type was generic.

[bowenni]

Thank you Wesley for the explanation!

[weswigham]

And I've got a fix up at #23884 😉