[Function Overloading] implementation is obviously different to the signatures, but no ts error

[shhider]

Bug Report

🔎 Search Terms

overload, implementation, signature, different, compatible

🕗 Version & Regression Information

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

⏯ Playground Link

code in playground

💻 Code

// signature
function foo(xx: number): number;
function foo(xx: number, yy: string): string;

// implementation
// ❗️it may return `boolean`, differing to the signatures
function foo(xx: number, yy?: string): number | string | boolean {
    if (yy == null) {
        return xx;
    }
    if (yy === "666") {
        return true;
    }
    return yy;
}

🙁 Actual behavior

Obviously, the implementation doesn't satisfy the signatures, but TS didn't "find" it. It confused me, and brought some issues into my project.

I don't know whether it is by-design or a bug, and I didn't find any doc about this behavior. Please tell me the reason of this design, if it is by-design.

🙂 Expected behavior

// signature
// EXPECTED: Tell me "This overload signature is not compatible with its implementation signature."
function foo(xx: number): number;
function foo(xx: number, yy: string): string;

// implementation
function foo(xx: number, yy?: string): number | string | boolean {
    // ...
}

[fatcerberus]

Overload checking is necessarily loose because it's pretty much impossible to constrain it in a way that makes it fully sound without overcomplicating the rules and getting in the way. For example, the same kind of unsoundness happens even with the "correct" signature:

// signature
function foo(xx: number): number;
function foo(xx: number, yy: string): string;

// implementation
function foo(xx: number, yy?: string): number | string {
    return 42;  // unconditionally returns a number
}

...namely that nothing prevents you from returning the wrong type for the overload that was actually called. There doesn't really seem to be an easily generalizable mechanism by which you could reject the case in the OP without also rejecting the "correct" signature, either, since both cases involve a return type which is simultaneously wider than both overloads'. So what would the rule for that be?

[jcalz]

Duplicate #52478 and ultimately #13235

[microsoft-github-policy-service]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.