Skip to content
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

keyof collapses the expression when used in a mapped type #55129

Closed
Mad-Kat opened this issue Jul 24, 2023 · 2 comments Β· Fixed by #55140
Closed

keyof collapses the expression when used in a mapped type #55129

Mad-Kat opened this issue Jul 24, 2023 · 2 comments Β· Fixed by #55140
Labels
Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Milestone

Comments

@Mad-Kat
Copy link

Mad-Kat commented Jul 24, 2023

Bug Report

πŸ”Ž Search Terms

  • keyof union generic
  • keyof union
  • keyof

πŸ•— Version & Regression Information

  • Since 4.1.5 (Playground test where mapping works)

⏯ Playground Link

Playground link with relevant code

πŸ’» Code

type Fruit =
  | {
      name: "apple";
      color: "red";
    }
  | {
      name: "banana";
      color: "yellow";
    }
  | {
      name: "orange";
      color: "orange";
    };

type Result1<T extends {name: string | number; color: string | number }> = {
  [Key in T as `${Key['name']}:${Key['color']}`]: unknown
}; 
type Result2<T extends {name: string | number; color: string | number }> = keyof {
  [Key in T as `${Key['name']}:${Key['color']}`]: unknown
}

// should be "apple:red" | "banana:yellow" | "orange:orange"
type Test1 = keyof Result1<Fruit> // this works

// should be "apple:red" | "banana:yellow" | "orange:orange"
type Test2 = Result2<Fruit> // this doesn't work and I'm not sure why :D

πŸ™ Actual behavior

  • Test2 is "apple:red" | "apple:yellow" | "apple:orange" | "banana:red" | "banana:yellow" | "banana:orange" | "strawberry:red" | "strawberry:yellow" | "strawberry:orange"
  • Somehow Result2 is collapsed:
    image

πŸ™‚ Expected behavior

  • Test2 should be "apple:red" | "banana:yellow" | "orange:orange"
@fatcerberus
Copy link

fatcerberus commented Jul 24, 2023

Result1 is distributive (i.e. it Array.maps over the individual union members of T, basically). I'm not sure of the exact rules for when a mapped type is distributive or not, but adding the keyof in Result2 seems to be disabling it.

@RyanCavanaugh RyanCavanaugh added the Question An issue which isn't directly actionable in code label Jul 24, 2023
@Andarist
Copy link
Contributor

Andarist commented Jul 24, 2023

I think this should be classified as a bug and not a question :p I prepared a fix for this but regardless of the fact if my fix is right or not, I think this is just a bug.

keyof here doesn't really turn off the distributivity of this mapped type. It's just an accidental simplification of this index type (where an index type is a keyof T). It happens before the final instantiation here. This call instantiates ${Key['name']}:${Key['color']} to ${T['name']}:${T['color']} and later when T gets instantiated with Fruit the compiler is evaluating that to all possible permutations. By that time it lost the fact that T at both sites has to be identical/a single member of the union.

A similar thing happens with:

declare const str: "a" | "b"
const output = `${str}:${str}` as const

The output's type is "a:a" | "a:b" | "b:a" | "b:b" but in reality, it can only be "a:a" | "b:b". This case is much harder to fix though, while the case presented here can be fixed by avoiding simplification (deferring resolution) at the generic level.

@RyanCavanaugh RyanCavanaugh added Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases and removed Question An issue which isn't directly actionable in code labels Jul 25, 2023
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Jul 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants