Spreads instantiated with array subtypes types exhibit bad behavior

[DanielRosenwasser]

Found by playing around with Matt McCutchen (@mattmccutchen)'s example at #26013 (comment):

interface CoolArray<E> extends Array<E> { 
 hello: number;
}

declare function foo<T extends any[]>(cb: (...args: T) => void): void;

foo<CoolArray<any>>(); // error
foo<CoolArray<any>>(100); // error
foo<CoolArray<any>>(foo); // no error!!

Expected: All of these calls produce an error and have a good error message.
Actual: The first two have bad errors, the last one is considered okay.

[DanielRosenwasser]

It might be difficult, but I think ideally the user would get an error message on the type argument during instantiation; something along the lines of

'{0}' is used as a spread parameter type and cannot be instantiated with this type.
 Only arrays and tuple types may be used as spread parameter types.

[ahejlsberg]

The tricky issue here is that constraints can only limit us to subtypes of arrays, but not specifically to instantiations of Array<T> or a tuple type. It would effectively require a new type of constraint to completely tighten this down. Erroring during instantiation is really a non-option because we simply aren't equipped to pinpoint the source location that caused the error. A core assumption is that instantiation is error free and that any errors are caught during constraint checking.

[RyanCavanaugh]

The last call should not be an error

[ahejlsberg]

Here's a more obvious example of the issue:

function bar<T extends any[]>(...args: T): T {
 return args;
}

let a = bar(10, 20); // Ok: [10, 20]
let b = bar<CoolArray<number>>(10, 20); // Bad: CoolArray<number>

We'll never infer anything but instantiations of Array<T> or tuple types, but it is possible to explicitly specify a subtype. However, JavaScript always creates an array instance for a rest parameter, so there is no way args could actually be such a subtype.

[DanielRosenwasser]

Ryan Cavanaugh (@RyanCavanaugh) why do you think so? foo shouldn't have a parameter list that can be inferred to a non-array type.

[RyanCavanaugh]

Daniel Rosenwasser (@DanielRosenwasser) consider this code, which is representative of many functional libraries:

function fn<T extends any[]>(cb: (...args: T) => void, arr: T): T {
 cb.call(null, arr);
 return arr;
}

type MyTaggedArray = Array<number> & { "I promise it's sorted" };
const arr = [] as MyTaggedArray;
const arr2 = fn(x => x, arr);

There is nothing wrong with this code!

The error in Anders' example should be that the [10, 20] argument list is not assignable to CoolArray, not that the declaration of bar is somehow intrinsically wrong.

[ahejlsberg]

To recap, the problem in this issue as well as #26491 is that we have no expressible constraint that limits type parameters to only be instantiated with Array<T> or tuple types. What we can do however is detect situations where a spread parameter isn't exactly of one of those types and substitute never[] for that spread parameter type. This at least produces the expected errors in the examples above, although the appearance of a never type might be surprising.

[mattmccutchen]

If we change the rest parameter to never[], then call sites that pass zero arguments to the rest parameter will go unnoticed, right? ISTM it would be better to change the rest parameter to never.

[ahejlsberg]

Matt McCutchen (@mattmccutchen) It's more like if we have a union of all tuple types, we should substitute a tuple type with all never elements of a length that matches the shortest of those tuple types. Otherwise, we should substitute never[].

[mattmccutchen]

Anders Hejlsberg (@ahejlsberg) To emphasize the point, if we substitute never[], then the following code compiles (because the empty array is of type never[]) but accesses a nonexistent property at runtime:

interface CoolArray<E> extends Array<E> { 
 hello: number;
}
function bar<T extends any[]>(...args: T): T {
 return args;
}
console.log(bar<CoolArray<number>>().hello);

If we substitute never, then we get an error that the empty array isn't assignable to never. If you're concerned that we should only substitute a valid array or tuple type, then [never] should be necessary and sufficient to ensure that the call always generates a compile error (unless a never value or, alas, an any value is already in scope).