Skip to content
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

Functions with overloads don't automatically get types for their parameters #38625

Closed
fregante opened this issue May 17, 2020 · 1 comment
Closed
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed

Comments

@fregante
Copy link

TypeScript Version: 3.9.2

Search Terms:

noImplicitAny true
overloaded
inferred types

Code

I don't know the exact terms for what's happening in the first example. Are these parameters' "types being inferred"?

// `text` has type `string`
window.alert = (text) => {
	return window.alert(text);
}

// Both parameters are `any`, because `addEventListener` has overloads
window.addEventListener = (type, fn) => {
	return window.addEventListener(type, fn);
}

Expected behavior:
They should follow these types from lib.dom.d.ts:

addEventListener<K extends keyof WindowEventMap>(type: K, listener: (this: Window, ev: WindowEventMap[K]) => any, options?: boolean | AddEventListenerOptions): void;
addEventListener(type: string, listener: EventListenerOrEventListenerObject, options?: boolean | AddEventListenerOptions): void;

Actual behavior:

Parameter 'type' implicitly has an 'any' type. ts(7006)
Parameter 'fn' implicitly has an 'any' type. ts(7006)

Playground Link: https://www.typescriptlang.org/play/#src=window.alert%20%3D%20(text)%20%3D%3E%20%7B%0D%0A%09return%20window.alert(text)%3B%0D%0A%7D%0D%0A%0D%0Awindow.addEventListener%20%3D%20(type%2C%20fn)%20%3D%3E%20%7B%0D%0A%09return%20window.addEventListener(type%2C%20fn)%3B%0D%0A%7D

@RyanCavanaugh RyanCavanaugh added the Design Limitation Constraints of the existing architecture prevent this from being fixed label Jun 8, 2020
@RyanCavanaugh
Copy link
Member

For overload sets with "terminal" signatures that encompass all of the preceding ones, this is sufficient, but for other overload sets where there are "disjoint" signatures (e.g. number => string + string => number) this process doesn't produce correct results.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed
Projects
None yet
Development

No branches or pull requests

2 participants