You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
intersection type between two template literal type will never be 'never' type #60446
functionany(): any{thrownull;}consttest5: `miauth/${string}/check` & `${string}/timeline` =any();// ^?// this should be never but does not
🙁 Actual behavior
`miauth/${string}/check` & `${string}/timeline` will remain `miauth/${string}/check` & `${string}/timeline`
not coming never would cause problem with Indexed Access Types
functionany(): any{thrownull;}typeEndpoints={'test/timeline': 0,'test2/timeline': 0,'other endpoint': 2,[ep: `miauth/${string}/check`]: 1,// no error at test2 if comment}typeTimelineEndpoints=keyofEndpoints& `${string}/timeline`;consttest2: Endpoints[TimelineEndpoints]=any();consttest3: 0=test2;// This assignment should not have type errors,// but because `miauth/${string}/check` & `${string}/timeline` is not never,// test2 become 0|1 so we cannot assign test2 to test3.
What about get${string} & ${string}Prop? Should that reduce to get${string}Prop? This could get complicated.
I wanna say "no" - matching patterns up to patterns, while possible, I don't think is as intuitive as matching literals to patterns - I see leaving it as get${string} & ${string}Prop as fine. Especially since with something like a${string} & ${string}a, there's no simple template it could merge down to and actually be equivalent, without also extracting specific literal cases for common prefixes and postfixes, like "a" | a${string}a. So yeah, while it's possible, I think it's not as high value - there's probably more clarity in retaining the input patterns, anyway.
In general we don't have any static guarantees about any two types always producing never when intersected. There is definitely a gray line (literals do, some template literals do, but not all of them), but it is not computable in general to know if two arbitrary types have a nonzero overlap. I don't really want to complicate this logic any further than it already is just to further a problem that won't actually be solved.
Activity
Andarist commentedon Nov 7, 2024
The problem is not exclusive to template literals - string mappings are also affected:
jcalz commentedon Nov 7, 2024
Relevant #40598 (comment)
RyanCavanaugh commentedon Nov 7, 2024
In general we don't have any static guarantees about any two types always producing
neverwhen intersected. There is definitely a gray line (literals do, some template literals do, but not all of them), but it is not computable in general to know if two arbitrary types have a nonzero overlap. I don't really want to complicate this logic any further than it already is just to further a problem that won't actually be solved.typescript-bot commentedon Nov 10, 2024
This issue has been marked as "Not a Defect" and has seen no recent activity. It has been automatically closed for house-keeping purposes.