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
Variadic element of tuple-like intersection types are spreading incorrectly #40945
Expected behavior: for T1, I expected it to be [](empty tuple type) and for T2, I expected it to be [1, 2, 3].
Actual behavior: Both T1 and T2 became Array rather than tuple somehow. (T1 is deduced to never[], T2 is deduced to (3 | 1 | 2)[])
detailed explanation
In some perspective, unknown could be recognized as type of all types. Therefore, [unknown] is type of all type-level 1-tuples and intuitively, unknown[] is type of all type-level n-tuples.
So [] <: unknown[] is true (i.e. all empty type-level tuple is subtype of all type-level n-tuples) and you can check it simply with this code:
However, in spite of the fact that [] is subtype of unknown[] therefore [] & unknown[] is actually [], variadic element of [] & unknown[] somehow spreads as never[], which is incorrect and unintuitive.
Unintuitive, yes; not as good as we could do, yes; but “incorrect” is somewhat debatable. (As an aside, this issue led to a great conversation about whether never[] is conceptually the same as [], despite specific differences in their assignability.) At any rate, since never[] is not assignable to [], that’s a good argument for T1 being “incorrect,” but (3 | 1 | 2)[] is clearly a valid representation of [1, 2, 3]; it’s just not a very good one 😄
Out of curiosity, since there are 4 👍 on an issue that seems somewhat arcane, is this coming up in practice somewhere?
I was building type-level programming library since TS 4.1 finally added recursive conditional type alias. But after few hours, I encountered this issue and talked with others in twitter for a few days. That 👍seems to be added by people I know or discussed with me about this.
I agree on that T1 is not being incorrect, sorry for misusing word. However, I think we all agree on that ( 3 | 2 | 1 )[] is not a proper or useful typing at all at this point since some important informations are discarded and it might cause some unexpected problems. 🙂
(Sorry for loose formatting, I wrote this comment with my mobile phone...)
I was building type-level programming library since TS 4.1 finally added recursive conditional type alias. But after few hours, I encountered this issue and talked with others in twitter for a few days. That 👍seems to be added by people I know or discussed with me about this.
Similar scenario for me. I was trying to map nested tuple types.
Actually, this is also broken [...[1] & [unknown]]
I had a similar "issue" when trying to get a tuple back from a tuple augmented with other properties.
Investigation led me to the discovery that even [...([1,2,3] & unknown[])] was lossy
You will find bellow my different attempts at getting the tuple back. Explicitly iterating over the numeric keys worked but I was surprised I had to go this far.
Activity
andrewbranch commentedon Oct 7, 2020
Unintuitive, yes; not as good as we could do, yes; but “incorrect” is somewhat debatable. (As an aside, this issue led to a great conversation about whether
never[]is conceptually the same as[], despite specific differences in their assignability.) At any rate, sincenever[]is not assignable to[], that’s a good argument forT1being “incorrect,” but(3 | 1 | 2)[]is clearly a valid representation of[1, 2, 3]; it’s just not a very good one 😄Out of curiosity, since there are 4 👍 on an issue that seems somewhat arcane, is this coming up in practice somewhere?
ENvironmentSet commentedon Oct 7, 2020
I was building type-level programming library since TS 4.1 finally added recursive conditional type alias. But after few hours, I encountered this issue and talked with others in twitter for a few days. That 👍seems to be added by people I know or discussed with me about this.
ENvironmentSet commentedon Oct 8, 2020
I agree on that T1 is not being incorrect, sorry for misusing word. However, I think we all agree on that ( 3 | 2 | 1 )[] is not a proper or useful typing at all at this point since some important informations are discarded and it might cause some unexpected problems. 🙂
(Sorry for loose formatting, I wrote this comment with my mobile phone...)
sethveale commentedon Oct 23, 2020
Similar scenario for me. I was trying to map nested tuple types.
mkantor commentedon Mar 11, 2022
This also becomes an array type, even though both sides of the intersection were tuples to begin with:
geoffreytools commentedon Mar 11, 2022
Actually, this is also broken
[...[1] & [unknown]]I had a similar "issue" when trying to get a tuple back from a tuple augmented with other properties.
Investigation led me to the discovery that even
[...([1,2,3] & unknown[])]was lossyYou will find bellow my different attempts at getting the tuple back. Explicitly iterating over the numeric keys worked but I was surprised I had to go this far.