Repository navigation
Regression: Intersection of array and tuple not assignable to tuple #38348
Description
TypeScript Version: Nightly
Search Terms: tuple intersection array
Expected behavior:
Expected code to compile. It does compile with tsc 3.8, but does not compile with tsc 3.9 (Nightly).
Actual behavior:
In the code below, the following error is reported:
const x: [number, ...number[]]
Type 'number[] & [number, ...number[]]' is not assignable to type '[number, ...number[]]'.(2322)Code
const y: number[] & [number, ...number[]] = [1];
const x: [number, ...number[]] = y;Discussion
Presumably, this is related to the breaking change in 3.9 around handling of tuple types more strictly. I believe the code is correct however and should compile, because the array type number[] is a strict supertype of the tuple type [number, ...number[]] (surely?) - perhaps the special case unifying tuple types with matching element types to an array type hasn't been implemented?
Discovered by Jason Gore (@JasonGore) and Nick Wilson (@NWilson) (MSFT).
Output
"use strict";
const y = [1];
const x = y;Compiler Options
{
"compilerOptions": {
"noImplicitAny": true,
"strictNullChecks": true,
"strictFunctionTypes": true,
"strictPropertyInitialization": true,
"strictBindCallApply": true,
"noImplicitThis": true,
"noImplicitReturns": true,
"useDefineForClassFields": false,
"alwaysStrict": true,
"allowUnreachableCode": false,
"allowUnusedLabels": false,
"downlevelIteration": false,
"noEmitHelpers": false,
"noLib": false,
"noStrictGenericChecks": false,
"noUnusedLocals": false,
"noUnusedParameters": false,
"esModuleInterop": true,
"preserveConstEnums": false,
"removeComments": false,
"skipLibCheck": false,
"checkJs": false,
"allowJs": false,
"declaration": true,
"experimentalDecorators": false,
"emitDecoratorMetadata": false,
"target": "ES2017",
"module": "ESNext"
}
}Playground Link: Provided
Activity
JasonGore commentedon May 5, 2020
Also applies to
3.9.1-rc.DanielRosenwasser commentedon May 5, 2020
I believe that this is because we no longer just consider intersections to be assignable if any constituent is assignable - the type has to be compatible as a whole. Anders Hejlsberg (@ahejlsberg) made that change at #37195
Is there a specific reason you had a
number[] & [number, ...number[]]?ahejlsberg commentedon May 6, 2020
The issue here is that we lack the ability to relate a tuple type with a rest element on the target side to anything but another tuple type on the source side. In the extra check introduced by #37195, the source type is an intersection, and so the check fails. I think an easy and reasonable fix is to omit the extra check when the target is a tuple type with a rest element.
NWilson commentedon May 6, 2020
I can see it's correct that
number[]won't assign to[number, ...number[]]. But the intersection checking logic should realise that the two types being interescted are not unrelated, but that the tuple is a refinement of the array.For example, this works in Nightly:
Even though
{ x: number }can't be assigned to{ x : 1 }the checker doesn't do the thing where it requires both parts of the intersection type to be assignable to the target. So the logic is there correctly for objects; the case I ran into is the corresponding handling for an array+tuple intersection.NWilson commentedon May 6, 2020
Apologies, I didn't motivate this very well! The example was perhaps too minimal.
The full code looked more like this (reworked to a vaguely minimal example). I hope you can see what was being attempted. No apologies made for the code - it is what it is - and thinking some more I can see that the types could be improved, but it's less clear what's going on in the original code which is a bit more involved.
NWilson commentedon May 8, 2020
Wow, thank you so much for a quick fix!