TypeScript cannot deduce decomposed array type. about typescript HOT 13 CLOSED

#57904 (comment) is correct

T is assignable to A | B | C if there's a valid assignment from T to A, T to B, or T to C. That's it. The relationships between A, B, and C aren't considered.

TypeScript isn't a theorem prover and can't use the sort of "If it wasn't A, then it must have been B or C, and if it wasn't B, then it must have been C, therefore it's a C" logic that you're applying to reach that result.

from typescript.

The exact example given above can be easily rewritten to give the desired output, and be much simpler too:

type A = true;
let a: A = true;

Is this [] | [T] | [T, ...T] construction something that actually comes up in code or is it just a case of "I can reason that something is true, so the type checker should be able to prove it."?

from typescript.

It seems this issue was misconstrued over the course of discussion. The purpose of this issue is to resolve the specific case when an array type is compared against a union of tuples of varying length, not for any A, B, and C in A extends B | C. The hope was that TypeScript could reduce the union, but since the assumption in #57904 (comment) is correct (i.e. TypeScript implements unions as falling into at least one basket), it seems the compiler is limited in this area. Please feel free to close the issue.

@jcalz BTW, this case is very easily solved with an interval tree. You build a tree, get the intervals, then test for some conditions.

from typescript.

Gonna be pondering whether { x: string } > { y: number } for the purposes of that tree for the whole weekend 😉

from typescript.

@RyanCavanaugh I think there is a misunderstanding lol. The case in #57904 (comment) I was talking about is when you are comparing arrays and tuples of the same type (number[], [number], etc.). Nothing more general than that.

from typescript.

I don't see why it should. A mutable array with arbitrary amount of elements does neither extend a tuple that's always empty, nor a tuple with always exactly one element, nor a tuple that has at least one element.

from typescript.

I don't see why it should. A mutable array with arbitrary amount of elements does neither extend a tuple that's always empty, nor a tuple with always exactly one element, nor a tuple that has at least one element.

I'm sorry, I don't understand what is being stated here. Assuming you used tuple to distinguish between resizable and fixed-sized arrays, then it's incorrect to assume [string, ...string[]] is a tuple with at least 1 element. This can be seen with the base case [...string[]] which string[] extends correctly.

EDIT: Actually, I just understood your statement. It's a bit of a non-sequitur, but perhaps a well-motivated one. Of course a mutable array doesn't extend each of those types individually, but that doesn't imply it doesn't match their union. Now perhaps TypeScript implements unions as falling into at least one basket. If that's the case, then yes, your statement is correct, but that's the reason I created this issue because mathematically-speaking string[] extends the union.

EDIT 2: Also, note that string | string reduces to string, so there is some reduction. I'm not aware how far it extends, but this issue is basically saying we should reduce [] | [string] | [string, ...string[]] to string[].

from typescript.

• string[] is not assignable to []
• string[] is not assignable to [string]
• string[] is not assignable to [string, ...string[]]
• Therefore, string[] is not assignable to the union of those three types.

Union and intersection are best thought of as disjunction/conjunction on assignability. If a value is not assignable to any member of a union individually, it's not assignable to the union. It's similar to set union in this regard.

Also, [string, ...string[]] is indeed a tuple type (in terms of the TS type system); it's an entirely different class of type from a regular array type like string[]. The existence of variable-length "tuples" is mostly motivated by the need to model rest parameters in function signatures. So the distinction is explicit; it's not simply a matter of fixed- vs. variable-length.

from typescript.

It does seem inconsistent. If, conceptually, boolean extends true | false (only) when the union is taken as a whole, it follows that T[] extends [] | [T, ...T[]] in much the same way. [] | [T, ...T[]] could be reduced to [...T[]], which typescript does treat as equivalent to T[].

Edit: I take it back. [...T[]] extends T[] but not vice-versa.

Edit 2: Okay, typescript treats T[] and [...T[]] as equal. It treats [] | [T, ...T[]] as a subtype of [...T[]]. I guess [...T[]] is being promoted to T[], but should a tuple be promoted to an array? This still feels inconsistent.

from typescript.

If a value is not assignable to any member of a union individually, it's not assignable to the union.

This is completely false. @snarbies came up with the very simple example of boolean extends true | false.

from typescript.

Well to be fair, boolean is literally just an alias for true | false. I'm just grasping at straws trying to come up with a "conceptual union" that's not defined in terms of a union in typescript.

from typescript.

The kind of machinery needed to verify things like this in general seems like it would be unscalably expensive. Try to imagine implementing the compiler to notice this. Would it have to split every array type into a potentially unbounded union of various tuple types? Or look at every union of tuple types and try to figure out how to combine them? Would anyone have an idea of how this would happen in a scalable way? It feels like this @RyanCavanaugh Twitter thread: any straightforward analysis would quickly become impossible for all but the most trivial of cases.

from typescript.

@jun-sheaf Point taken, but since this is a type-level question (is type A assignable to type B), generally the preference is to have general rules that can be applied uniformly to any type rather than a bunch of special cases.

from typescript.