Repository navigation
Type inference on tuple intersection types broken #59521
Description
🔎 Search Terms
infer tuple intersection
🕗 Version & Regression Information
- Version 5.5.4
⏯ Playground Link
💻 Code
type Target = [number, string, boolean] & { att: string; };
type A = Readonly<Target>; // wishful thinking
type Head1 = Target extends [infer H, ...infer Tail] ? H : never; // doesn't work
type Head2 = Target extends [infer H, ...any[]] ? H : never; // works
type Tail1 = Target extends [infer H, ...infer Tail] ? Tail : never; // doesn't work
type Tail2 = Target extends [any, ...infer Tail] ? Tail : never; // doesn't work
type ReverseHead1 = Target extends [...infer RTail, infer RH] ? RH : never; // doesn't work
type ReverseHead2 = Target extends [...any[], infer RH] ? RH : never; // doesn't work
type ReverseTail1 = Target extends [...infer RTail, infer RH] ? RTail : never; // doesn't work
type ReverseTail2 = Target extends [...infer RTail, any] ? RTail : never; // doesn't work🙁 Actual behavior
Doesn't work
🙂 Expected behavior
Works
Additional information about the issue
I would expect Readonly<[number, string, boolean] & { att: string }> to be readonly [number, string, boolean] & { readonly att: string }, but that's wishful thinking. I'm sure you guys got a myriad of reasons and design limitations that don't allow it; weak types, homomorphic, variance, instantiation and whatnot.
In any case, I thought, whatever, I'll do it myself with some infers... but it looks like I won't be able to do the general case because infers break on tuple types that are intersected.
So, just letting you know in case you care... here are some unexpected behaviors ✌️
Activity