Repository navigation
TS 4.2: Type alias differs from original type #44119
Description
Bug Report
🔎 Search Terms
4.2 Type alias
🕗 Version & Regression Information
- This changed between versions 4.1.5 and 4.2.3
- Also reproducible in 4.3.0-beta and nightly
⏯ Playground Link
💻 Code
const func1 = (arg: Record<'field', string>) => { }
type Type1 = Record<'field', string>
const func2 = (arg: Type1) => { }
const arg: Record<string, string> = {}
func1(arg) // ok
func2(arg) // Property 'field' is missing in type 'Record<string, string>' but required in type 'Type1'.🙁 Actual behavior
Type alias Type1 differs from original type Record<'field', string>
🙂 Expected behavior
Types of func1 and func2 should be equal and behave the same way, as it worked on 4.1.5 and earlier
Activity
ahejlsberg commentedon May 26, 2021
The direct cause of this issue is #42284. We now preserve the alias for
Type1and thus when relating toRecord<'field', string>we are no longer relating instantiations of the same type alias. Therefore we relate the types structurally and we discover they're not compatible. The reason we viewRecord<'field', string>andRecord<string, string>as compatible has to do with the way we measure variance. We find that the first type parameter is contra-variant when in reality variance is strictly speaking unmeasurable for mapped types because astringkey turns into an index signature which doesn't exactly behave as an infinite number of properties.I'm pretty sure we already have a bug for this, but haven't been able to find it yet.
ahejlsberg commentedon May 26, 2021
I should add, I think we already tried marking variance of mapped types as unmeasurable, but it lead to an explosion in structural type comparisons with significant effects on performance.
ahejlsberg commentedon May 26, 2021
I found the issue we already have for this. Duplicate of #29698.