Homomorphic mapped generic array type sometimes no longer seen as an array about typescript

[ahejlsberg]

I'm considering the best way to fix this. The core issue is that mapped types applied to array intersections do not produce arrays, and that's is a design limitation. However, the error in the repro is a regression, which is unfortunate.

The workaround is to remove the constraint from the type parameter and instead add it through an indirection:

type MustBeArray<T extends any[]> = T

type Hmm2<T> = T extends number[] ?
    MustBeArray<{ [I in keyof T]: 1 }> :
    never;

type Hmm<T extends any[]> = Hmm2<T>;

type X = Hmm<[3, 4, 5]>

[ahejlsberg]

Right, the core issue is that when a homomorphic mapped type is applied to an intersection of array types, the resulting type isn't an array type:

type CheckArray<T extends any[]> = T;

type Mappy<T> = { [K in keyof T]: 1 };

type T0 = CheckArray<Mappy<[10, 20, 30]>>;  // [1, 1, 1]
type T1 = CheckArray<Mappy<string[]>>;  // 1[]
type T2 = CheckArray<Mappy<string[] & number[]>>;  // Error

The reason the error shows up in the OP is that with #57122 (which is in 5.4) we now recognize that the conditional type adds the constraint number[] to T in the true branch, meaning that when T is any[] we get the constraint any[] & number[].

The fix here is probably to distribute the homomorphic mapped type over intersections, i.e. treat Mappy<string[] & number[]> as Mappy<string[]> & Mappy<number[]>, but I need to think on this a bit.

[Andarist]

The constraint of T becomes number[] & any[] here (it comes from getBaseConstraint(getSubstitutionIntersection(t))) and that's not exactly something that satisfies isArrayOrTupleType check in getResolvedApparentTypeOfMappedType.

[jcalz]

Yeah, homomorphic mapped types "should" distribute over intersections, but I guess I find it a little surprising that the combination of two array constraints just produces an intersection to begin with, since intersections of array types are so problematic.

[ehoogeveen-medweb]

I would (perhaps naively) expect that number[] & string[] reduces to never or never[] and number[] & any[] reduces to number[] (or if any[] is weird, then at least with unknown[]). Is that (deliberately) not the case?

[jcalz]

Could someone triage this? Is it a bug/limitation/intended? If it's going to stick around like this for a while is there any workaround for people who run into it? Thanks!