Repository navigation
TypeScript cannot deduce decomposed array type. #57904
Description
🔎 Search Terms
array, types
🕗 Version & Regression Information
N/A
⏯ Playground Link
💻 Code
type A = string[] extends [] | [string] | [string, ...string[]] ? true : false;
let a: A = true;🙁 Actual behavior
The compiler throws because it doesn't understand the condition.
🙂 Expected behavior
The compiler should compile successfully.
Additional information about the issue
No response
Activity
MartinJohns commentedon Mar 22, 2024
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.
jrandolf-old commentedon Mar 22, 2024
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[]]whichstring[]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 | stringreduces tostring, 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[]]tostring[].fatcerberus commentedon Mar 22, 2024
string[]is not assignable to[]string[]is not assignable to[string]string[]is not assignable to[string, ...string[]]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 likestring[]. 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.snarbies commentedon Mar 22, 2024
It does seem inconsistent. If, conceptually,
booleanextendstrue | false(only) when the union is taken as a whole, it follows thatT[]extends[] | [T, ...T[]]in much the same way.[] | [T, ...T[]]could be reduced to[...T[]], which typescript does treat as equivalent toT[].Edit:
I take it back.[...T[]]extendsT[]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 toT[], but should a tuple be promoted to an array? This still feels inconsistent.jrandolf-old commentedon Mar 22, 2024
This is completely false. snarbies came up with the very simple example of
boolean extends true | false.snarbies commentedon Mar 22, 2024
Well to be fair,
booleanis literally just an alias fortrue | 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.nmain commentedon Mar 22, 2024
The exact example given above can be easily rewritten to give the desired output, and be much simpler too:
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."?RyanCavanaugh commentedon Mar 22, 2024
#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.
jcalz commentedon Mar 22, 2024
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.
jrandolf-old commentedon Mar 22, 2024
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, andCinA 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.Joe Calzaretta (@jcalz) BTW, this case is very easily solved with an interval tree. You build a tree, get the intervals, then test for some conditions.
RyanCavanaugh commentedon Mar 22, 2024
Gonna be pondering whether
{ x: string } > { y: number }for the purposes of that tree for the whole weekend 😉jrandolf-old commentedon Mar 22, 2024
Ryan Cavanaugh (@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.fatcerberus commentedon Mar 22, 2024
@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.