Regression: Type using conditional and mapped types is no longer assignable in 4.3

[dragomirtitian]

Bug Report

🔎 Search Terms

assignability regression

🕗 Version & Regression Information

• This changed between versions 4.2 and 4.3-beta

⏯ Playground Link

Playground link with relevant code

💻 Code

export type UnrollOnHover<O extends object> = O extends object ?
    { [K in keyof O]: O[K]; } :
    never;


export type Schema = Record<string, unknown>;
class Table<S extends Schema>  {
    __schema!: S;

    // Removing this line, removes the error 
    getRows<C extends keyof S>(): Array<UnrollOnHover<Pick<S, C>>> {
        return null!
    }
}

class ColumnSelectViewImp<S extends Schema> extends Table<S> { }


const ColumnSelectView1: new <S extends Schema>() => Table<UnrollOnHover<S>> = ColumnSelectViewImp;
const ColumnSelectView2: new <S extends Schema>() => Table<UnrollOnHover<S>> = Table;

🙁 Actual behavior

Assignment to ColumnSelectView1 failed

🙂 Expected behavior

Assignment to ColumnSelectView1 succeeds as it did in 4.2

Workaround

Wrap S in UnrollOnHover as well Playground link

[weswigham]

Yep, like I suspected, this was caused by a change in inference. Namely, we used to erase local type parameters to any, while now we map them into their constraints. So in earlier versions of TS, we'd replace C with any, resolve the Pick into an object with some index signatures, and match up the index signature type S[any] against UnrollOnHover<S>[string] (getting S = UnrollOnHover<S>, same as the other inference site). Now, UnrollOnHover remains unexecuted, because C is only replaced with keyof S., so instead, we're matching {[k: string]: S[any]} to UnrollOnHover<Pick<UnrollOnHover<S>, keyof UnrollOnHover<S>>>, which, when we look at the mapped type in UnrollOnHover, looks like {[K in keyof Pick<UnrollOnHover<S>, keyof UnrollOnHover<S>>]: Pick<UnrollOnHover<S>, keyof UnrollOnHover<S>>[K]} and wouldn't ya know, that template matches up to the index signature type and we match S to Pick<UnrollOnHover<S>, keyof UnrollOnHover<S>>.

The new inference is definitely valid (certainly, it's an expression of the same type, even if we don't always recognize it as such) - it's an inference we always could have made (albeit with more contortions), it's just really unfortunate, since it's at the same priority as the other inference site (and last-in-wins). I have put up a PR (#44126) that lowers the priority of the secondary inference site in structures like this one, so the mapped-over structure is a lower priority than the plain type parameter, which gets back the old inference and thus assignability behavior.

[dragomirtitian]

@DanielRosenwasser @RyanCavanaugh This does not appear fixed in 4.3.2 (Playground Link) but works in nightly (Playground Link). Will there be a 4.3.3 where this will be included ?