Repository navigation
Inconsistent incompatible types error for a sparse array type declaration #50351
Closed as not planned
Description
Bug Report
🔎 Search Terms
incompatible types inconsistent
🕗 Version & Regression Information
The behavior changes between 4.4.4 and 4.5.5, but the previous state wasn't the expected result either.
⏯ Playground Link
Playground link with relevant code
💻 Code
export interface ReadonlySparseArray<T> {
readonly length: number;
slice(start?: number, end?: number): SparseArray<T>;
every<S extends T>(
predicate: (value: T, index: number) => value is S,
): this is ReadonlySparseArray<S>;
readonly [n: number]: T | undefined;
flatMap<U>(callback: (value: T, index: number) => U | readonly U[] | ReadonlySparseArray<U>): U[];
}
export interface SparseArray<T> extends ReadonlySparseArray<T> {
[n: number]: T | undefined;
}
// const _a: SparseArray<string> = ['a'];
export function foo<T>(): ReadonlySparseArray<T> {
let a: T[] = [];
return a;
}🙁 Actual behavior
The code above reports:
Type 'T[]' is not assignable to type 'ReadonlySparseArray<T>'.
The types returned by 'slice(...).flatMap(...)' are incompatible between these types.
Type '(U | ReadonlySparseArray<U>)[]' is not assignable to type 'U[]'.
Type 'U | ReadonlySparseArray<U>' is not assignable to type 'U'.
'U' could be instantiated with an arbitrary type which could be unrelated to 'U | ReadonlySparseArray<U>'.
on return a;.
However, if the const _a line is uncommented, the error goes away. If you move that line to after the generic function, both places report this error.
(Weirdly, if you remove the every method from the ReadonlySparseArray, both places would be reporting the error regardless of the place of the const _a line.)
🙂 Expected behavior
It should not report error, since SparseArray and ReadonlySparseArray here should be compatible with array type. It's just a declaration of some of its methods.
Activity
upsuper commentedon Aug 20, 2022
Rethought about it, I now believe that the correct behavior is that TypeScript should consistently reject it. Because for
flatMap,U | readonly U[]is a subtype ofU | readonly U[] | ReadonlySparseArray<T>(and not the reverse, since sparse array is not supposed to be assignable to dense array), so(...) => U | readonly U[]is a subtype of(...) => U | readonly U[] | ReadonlySparseArray<T>, thus(callback: (...) => U | readonly U[] | ReadonlySparseArray<T>) => U[]is a subtype of(callback: (...) => U | readonly U[]) => U[], which meansReadonlyArray.flatMapshould not be assignable toReadonlySparseArray.flatMaphere.andrewbranch commentedon Apr 24, 2024
This is caused by a false positive of
isDeeplyNestedType. Xidorn Quan (@upsuper) is correct thatflatMapshould consistently cause an assignability error. However, because of the interconnected return types in the methods ofReadonlySparseArrayandSparseArrayand the order they’re written, we end up bailing out of comparingflatMapjust barely too early. The comparison stack at the point of bailing looks like:(literal) Array<string>SparseArray<string>(literal) Array<string>["slice"]SparseArray<string>["slice"]Array<string>SparseArray<string>Array<string>["every"]SparseArray<string>["every"]Array<any>ReadonlySparseArray<any>Array<any>["slice"]ReadonlySparseArray<any>["slice"]Array<any>SparseArray["any"]Array<any>["flatMap"]SparseArray<any>["flatMap"]U | ReadonlyArray<U | ReadonlySparseArray<U>> | ReadonlySparseArray<U>U | ReadonlyArray<U> | ReadonlySparseArray<U>ReadonlyArray<U | ReadonlySparseArray<U>>ReadonlySparseArray<U>ReadonlyArray<U | ReadonlySparseArray<U>>["slice"]ReadonlySparseArray<U>["slice"]Array<U | ReadonlySparseArray<U>>SparseArray<U>While this looks pretty chaotic, it does finish with the correct results if you bump the
maxDepthparameter ofisDeeplyNestedTypefrom3to4, with the following error elaboration:Note that the comparison at index 8 is the result of contextual signature instantiation after a potentially questionable inference explained here. That’s a separate bug, but fixing it would probably prevent this particular example from triggering the depth limiter.
andrewbranch commentedon Apr 26, 2024
#58321 fixes this by changing the weird inference mentioned above, but I feel like it’s probably wrong
andrewbranch commentedon Jul 29, 2024
Anders Hejlsberg (@ahejlsberg) says possibly related to #56291 and #55666
typescript-bot commentedon Aug 1, 2024
This issue has been marked as "Design Limitation" and has seen no recent activity. It has been automatically closed for house-keeping purposes.