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

Union in template literal simplifying unexpectedly #58340

Closed
rj-lee opened this issue Apr 27, 2024 · 6 comments
Closed

Union in template literal simplifying unexpectedly #58340

rj-lee opened this issue Apr 27, 2024 · 6 comments
Labels
Not a Defect This behavior is one of several equally-correct options

Comments

@rj-lee
Copy link

rj-lee commented Apr 27, 2024

πŸ”Ž Search Terms

template literal union distributive conditional type

πŸ•— Version & Regression Information

5.4.5 and Nightly

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.4.5#code/C4TwDgpgBAYg9nAclAvFABgMwQEgN4DkAjAAwkFQA+UAFOvgHYCuAtgEYQBOAvulAGRQ83AJS8A3ACgA9NKihIsBMjRZceenmbsuvAUO68ZciAA9IAY2AQAJqigAibHFIkHVDM-ybtHHn0FhXiA

πŸ’» Code

type FooN = `foo${'100' | (`${number}` & {})}`;
// type FooN = `foo${`${number}` & {}}`
// expected = "foo100" | `foo${`${number}` & {}}`

πŸ™ Actual behavior

'100' and `${number}` & {} are being simplified to `${number}` & {}. FooN does not have autocomplete for 'foo100'

πŸ™‚ Expected behavior

FooN should be of type "foo100" | `foo${`${number}` & {}} and provide autocomplete for foo100 while allowing foo101 or any other number

Additional information about the issue

No response

@jcalz
Copy link
Contributor

jcalz commented Apr 27, 2024

(There are no distributive conditional types in this issue)

#48034 #48044 #49839 #54188 #54648 #56458 #57807 #57918

From previous issues having to do with branded primitives in template literals, it's not clear what the "correct" behavior should be here. Looks like different people have very different expectations.

@rj-lee
Copy link
Author

rj-lee commented Apr 27, 2024

I can see how people might want it differently, but what if we wanted to intentionally distribute it?

type Foo<T extends string> = T extends T ? `foo${T}` : never;
type FooN = Foo<`100` | `${number & {}}`>;
// FooN is still `foo${number & {}}`

@RyanCavanaugh RyanCavanaugh added the Not a Defect This behavior is one of several equally-correct options label Apr 29, 2024
@RyanCavanaugh
Copy link
Member

I don't know any good way to reason about this. Either foo100 is a foo${number & {}}, in which case reduction is correct, or it isn't, in which case foo${number & {}} has no constituents.

@jcalz
Copy link
Contributor

jcalz commented Apr 29, 2024

Possibly if #33471 is ever implemented there would be a way to have this work also. The issue isn’t that the reduction is incorrect, but that it obscures information people want to keep around.

@fatcerberus
Copy link

@RyanCavanaugh I assume this to be the template-string analogue of

type T = 1 | 2 | 3 | (number & {});

which is (IIUC, very much intentionally) not reduced today even though 1 | 2 | 3 are all subsumed by number & {}

@typescript-bot
Copy link
Collaborator

This issue has been marked as "Not a Defect" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

@typescript-bot typescript-bot closed this as not planned Won't fix, can't repro, duplicate, stale May 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Not a Defect This behavior is one of several equally-correct options
Projects
None yet
Development

No branches or pull requests

5 participants