Repository navigation
Implementation of concat gives unexpected results #39241
Description
function concat1<T extends readonly any[], U extends readonly any[]>(arr1: T, arr2: U): [...T, ...U] {
return [...arr1, ...arr2];
}
function concat2<T extends readonly any[], U extends readonly any[]>(arr1: T, arr2: U) {
return [...arr1, ...arr2];
}
const x1 = concat1([1,2,3] as const, [4,5, 6] as const);
const x2 = concat2([1,2,3] as const, [4,5, 6] as const);Here, TypeScript is okay with concat1 returning [...T, ...U], but instead infers the type of concat2 to be T[number][].
Notice U was not in the output type!
As a result, x1 has the type [1, 2, 3, 4, 5, 6] and x2 has the type (1, 2, 3)[]).
Activity
DanielRosenwasser commentedon Jun 24, 2020
Feels strange to contrast with
tailwhich works as one would expect:DanielRosenwasser commentedon Jun 24, 2020
Anders Hejlsberg (@ahejlsberg) any thoughts on this one?
ahejlsberg commentedon Jun 25, 2020
Yeah, inferring
T[number][]instead of(T[number] | U[number])[]definitely isn't good. We actually do ask for a union of those two types, but sadly subtype reduction reduces it toT[number][]. The issue is the rule we have that says a type is assignable toT[K]if it is assignable to the base constraint ofT[K]for writing. And the base constraint ofT[K]for both reading and writing isany. The rule is unsound (for sure), but we have it to allow assignment of non-generic types to typethis['foo']in classes. I'm thinking we should restrict it to not kick in for index signatures inT.ahejlsberg commentedon Jun 25, 2020
BTW, the fact that we infer an array type for
concat2is by design, it doesn't have a tuple contextual type nor is itas const. Not clear that we could easily change that.ahejlsberg commentedon Jun 25, 2020
Actually, there's really no reason the unsound rule should be in effect for anything but the assignable and comparable relations. So, I think the fix is to disable it for the subtype relations, which causes us to preserve the full
(T[number] | U[number])[]. I will put up a PR.