Skip to content

Unexpected return type of overloaded function #59251

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
rotu opened this issue Jul 12, 2024 · 2 comments
Closed

Unexpected return type of overloaded function #59251

rotu opened this issue Jul 12, 2024 · 2 comments

Comments

@rotu
Copy link

rotu commented Jul 12, 2024

πŸ”Ž Search Terms

overload, multiple call signature

πŸ•— Version & Regression Information

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

⏯ Playground Link

https://www.typescriptlang.org/play/?target=99&jsx=0&ts=4.8.4&q=5#code/JYOwLgpgTgZghgYwgAgHIHswG8BQz-IAUAHgFzIBG66ANhHCAJTlW30gDceBJ58NAZwjNkYKAFcIXAkTKiJwvnEFTu+XpWp0GI1ts44AvjhwATCAhpwoKAG7XkITKQxgcCdCAFhHmAIIgAJ7IALy+YIRikshwAjFBjMgA9Eny0QCEAPxZOCkyAHqZQA

πŸ’» Code

interface Not{
    (x: boolean): boolean;
    (x: false): true;
    (x: true): false;
    (x: boolean): boolean;
}

declare var not:Not
const notAny = not(true as any) // true !?!?
//    ^?

πŸ™ Actual behavior

The type of notAny is inferred as true, the return type of the second overload call signature.

πŸ™‚ Expected behavior

The type of notAny should infer to boolean, as the first applicable signature without assignment to any (described as the expected behavior here)

Alternately the type of notAny should infer to boolean as the last signature (and thus the type ReturnType<Not>).

Additional information about the issue

Variation of this issue originally reported in #59064.

@rotu rotu changed the title Overload call signature resolution resolves inconsistently Unexpected return type of overloaded function Jul 12, 2024
@MartinJohns
Copy link
Contributor

This still sounds like a duplicate of #39833.

@rotu
Copy link
Author

rotu commented Jul 12, 2024

This still sounds like a duplicate of #39833.

Looking at that issue again, I think it is.

I interpreted the referenced comment to mean "assignment to a parameter of type any" not "assignment from an argument of type any", so I may have missed that.

as the first applicable signature without assignment to any (described as the expected behavior here)

@rotu rotu closed this as not planned Won't fix, can't repro, duplicate, stale Jul 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants