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
Key in mapped variadic tuple should not be literal after the variadic partΒ #48856
A and B both have the variadic part typed as ..."1"[], which is wrong. B is further wrong because the number part becomes "2", while in practice it would rarely be "2".
π Expected behavior
A should be ["0", ...number[]]; B should be ["0", ...number[], number]
With the proposed change, P would be number instead of "2" for the rest element, which means the resulting rest element would be ...Box<string | number | boolean>[] instead of just ...Box<boolean[]>. Not only is that less correct, it is a breaking change. Effectively, number is a less precise way of expressing "element at index 2 or above", whereas "2" gets much closer. This speaks to the fact that in homomorphic mappings over array and tuple types, the key types are just exemplars and not an exact representation of some specific property.
I also thought about that. The problem is it's really hard to be correct for both the key type itself, and for homomorphic mapped types to continue be homomorphic. However, accessing T[P] and P directly should be two orthogonal actions. In my actual case, I'm doing Entries instead of Keys:
In an ideal world, I'd like Entries<[number, string, ...boolean[]]> to be [["0", number], ["1", string], ...[number, boolean][]]. Does that sound reasonable?
If we have subtracted types, the index should rather by Exclude<number, 0 | 1>, but since we are not there yet, I'd be more happy with number than 2 as the index type.
Activity
ahejlsberg commentedon Apr 27, 2022
I don't think this is a bug. Consider:
With the proposed change,
Pwould benumberinstead of"2"for the rest element, which means the resulting rest element would be...Box<string | number | boolean>[]instead of just...Box<boolean[]>. Not only is that less correct, it is a breaking change. Effectively,numberis a less precise way of expressing "element at index 2 or above", whereas"2"gets much closer. This speaks to the fact that in homomorphic mappings over array and tuple types, the key types are just exemplars and not an exact representation of some specific property.Josh-Cena commentedon Apr 28, 2022
I also thought about that. The problem is it's really hard to be correct for both the key type itself, and for homomorphic mapped types to continue be homomorphic. However, accessing
T[P]andPdirectly should be two orthogonal actions. In my actual case, I'm doingEntriesinstead ofKeys:In an ideal world, I'd like
Entries<[number, string, ...boolean[]]>to be[["0", number], ["1", string], ...[number, boolean][]]. Does that sound reasonable?If we have subtracted types, the index should rather by
Exclude<number, 0 | 1>, but since we are not there yet, I'd be more happy withnumberthan2as the index type.typescript-bot commentedon Apr 30, 2022
This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.
ahejlsberg commentedon Jan 11, 2024
Joshua Chen (@Josh-Cena) FWIW, I now agree with your observations and suggested changes. See #57031. Better late than never! π