Skip to content

TS 4.2: Type alias differs from original type #44119

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking β€œSign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
YauheniKhadanionak opened this issue May 17, 2021 Β· 3 comments
Closed

TS 4.2: Type alias differs from original type #44119

YauheniKhadanionak opened this issue May 17, 2021 Β· 3 comments
Assignees
Labels
Duplicate An existing issue was already created

Comments

@YauheniKhadanionak
Copy link

YauheniKhadanionak commented May 17, 2021 β€’

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

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

@DanielRosenwasser DanielRosenwasser added the Bug A bug in TypeScript label May 25, 2021
@DanielRosenwasser DanielRosenwasser added this to the TypeScript 4.4.0 milestone May 25, 2021
@ahejlsberg
Copy link
Member

The direct cause of this issue is #42284. We now preserve the alias for Type1 and thus when relating to Record<'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 view Record<'field', string> and Record<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 a string key 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
Copy link
Member

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
Copy link
Member

I found the issue we already have for this. Duplicate of #29698.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

3 participants