String literal type inconsistency in overload resolution

[zhuravlikjb]

As far as I see, the TS compiler still sees a string literal type of a single literal as an old style "string parameter" thing. I thought that the concept of string literal types should replace overloading on string parameters, but seems that it doesn't.

That complicates things, and results in a "strange" behaviour in overload resolution:

class A256 {
    m(a): any;
    m(a: "a" | "b"): string;
    m(a: "c"): string;
    m(a): any {}
}

var foo1 = new A256().m("a"); // 'any'
var foo2 = new A256().m("c"); // 'string'

What should be the correct logic with string literal types in overload resolution?
Shouldn't overloads with unions of literals precede the others as well, when resolving overloads?

[sbliven]

Typescript's handling of overloads is very confusing. From the manual:

In order for the compiler to pick the correct typecheck, it follows a similar process to the underlying JavaScript. It looks at the overload list, and proceeding with the first overload attempts to call the function with the provided parameters. If it finds a match, it picks this overload as the correct overload. For this reason, it’s customary to order overloads from most specific to least specific.

From that, I would have expected both foo1 and foo2 to be typed as any. However, it's potentially debatable since you're not following the 'most specific to least specific' rule of thumb. Removing the first m(a): any declaration causes both variables to be string, as expected from the "a" and "c" definitions.

One problem here is that duplicate overloads get ordered inconsistently. Maybe the compiler should raise an error on duplicate overloads for this reason, although that might be hard due to the way inheritance is handled internally.

Another problem here is that it compiles at all with this function body, given that the function returns undefined. That definitely violates type safety.

[mister-walter]

I ran into this issue recently with a similar example (playground link):

function f4(x: string): string;
function f4(x: "foo"): number;
function f4(x: number): boolean;
function f4(x: number): string;
function f4(x: any): any {
    return x;
}

// note that the type of x is inferred to be number.
// This is different from what the old typescript documentation stated, e.g.
// that overloads would be processed from top to bottom, selecting the first
// matching overload.
// In this case, I would expect the first matching overload for f4 with the
// argument "foo" to be f4(x: string): string.
let x = f4("foo");

// y is inferred to have type boolean, which is consistent with the
// top-to-bottom first matching order.
let y = f4(3);

// note that if the type is a union, the resolution is consistent with the
// top-to-bottom first matching order.
function f8(x: string): string;
function f8(x: "foo"|"bar"): number;
function f8(x: any): any {
    return x;
}

// both inferred to have type string
let z = f8("foo");
let w = f8("baz");

Note that the new version of the Handbook does not discuss the order in which overloads are resolved at all. I can put together a PR to include information about function overload resolution order on that page if desired, but I want to double check that my understanding is correct first.

As a result of changes made due to #1133, it seems that during overload resolution, resolution candidates are reordered, with signatures that contain specialized types (according to the old language spec this only refers to string literal types, but in practice it seems like this also applies to number literals) ordered before any other signatures. AFAICT unions of string literals or number literals are not considered specialized types.

Thus, the overload resolution order appears to be (ignoring inheritance):

• If no overloaded signatures contain specialized types, the first signature (in declaration order) that matches the argument types is chosen.
• If any of the overloaded signatures contain specialized types (e.g. string or number literal types), then those signatures are checked first (in declaration order) and if any match, that signature is chosen as the resolved overload. If none of those signatures match the argument types of the call in question, then the remaining signatures are checked as usual: the first signature (in declaration order) that matches the argument types is chosen.