Overloaded function with at least one generic overload can be assigned to any function with at least the same number of parameters

[otonashixav]

Bug Report

🔎 Search Terms

overload, generic, function

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about overloads and generics.

⏯ Playground Link

Playground link with relevant code

💻 Code

// only overloaded
function a(value: string): void;
function a(value: number): void;
function a(value: string | number) { value.toString() };

// only generic
function b<T extends number>(value: T): void { value.toString() };

// overloaded with generic
function c(value: string): void;
function c<T extends number>(value: T): void;
function c(value: string | number) { value.toString() };

// these are errors as expected
() => {
    let d: (value: unknown) => void = a;
    let e: (value: unknown) => void = b;
    c(null);
}

// this should be an error
let f: (value: unknown) => void = c;
f(null);

🙁 Actual behavior

In the example above I call f(null) and cause a runtime error, however typescript doesn't warn me about it.

🙂 Expected behavior

c should not be assignable to (value: unknown) => void.

[ahejlsberg]

This is a known and long standing issue. In overloaded functions we erase type parameters (by substituting the any type) when relating signatures. From a comment in signaturesRelatedTo:

// For simple functions (functions with a single signature) we only erase type parameters for
// the comparable relation. Otherwise, if the source signature is generic, we instantiate it
// in the context of the target signature before checking the relationship. Ideally we'd do
// this regardless of the number of signatures, but the potential costs are prohibitive due
// to the quadratic nature of the logic below.

We could reconsider and attempt to fix this, but it will undoubtedly be a breaking change. For example, in #48092 we stop erasing type parameters for instantiations of the same generic type, but we never merged that PR due to the breaks it created.

This issue is basically a duplicate of #26631, and probably several others.

[niklasholm]

@ahejlsberg Interesting, I ran into a similar issue where the compiler would accept unsound generic overload signatures and came looking for answers, but found nothing in the documentation. If the compiler replaces generic types in overload signatures with any, the behavior I'm seeing makes sense. Should there not be some mention of this pretty serious limitation in the documentation?