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

Callback argument type not inferred for union of interfaces #59309

Open
nwalters512 opened this issue Jul 16, 2024 · 1 comment Β· May be fixed by #59672
Open

Callback argument type not inferred for union of interfaces #59309

nwalters512 opened this issue Jul 16, 2024 · 1 comment Β· May be fixed by #59672
Labels
Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Milestone

Comments

@nwalters512
Copy link

nwalters512 commented Jul 16, 2024

πŸ”Ž Search Terms

"implicitly has an" inference

πŸ•— Version & Regression Information

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

⏯ Playground Link

https://www.typescriptlang.org/play/?target=5&ts=5.5.3#code/KYDwDg9gTgLgBASwHY2FAZgQwMbDgQQGcBPJbAJWEIFcAbGAYU1toCMcBrAHgBUAaOAFE4AXiFQo0AHxwA3gFgAUHBVwAFGigB+AFxC4AHzhI6tAVCp0YuuDwCUegG4QEAEwDcSgL5KloSLCIKGhYuAQkZJQ09ACSqFCYMNC8AuQCwmKCEtJySqrqCKgAtnr8cNjMbJx6RKQUlvRMLOzY3GlCUg5wzm6eij6K-tDwyPGheLWRDTBxaInQAAqSRQiEwClw5DIKyqpqhcAltl1LECtrXFt9A0quwNi0mBZw6NRkMAgQSHBFmGAAMggVjANu0MuJJFApGo8qonlBSgBtAC6fFhKloQMKehMRVYaDRuxUBwSSQRKkm9WiM3i8ygp3O6zKW0M4TqUSss1JyWZ6SkhJOy1W63IKKkfSUvwBWJgakRAEY+AAmPgAZlRcFVAkwEWw6iQdlE23RcAsMGoUG+3wAVNa4ErrnZ3EA

πŸ’» Code

export interface AsyncResultCallback<T, E = Error> {
    (err?: E | null, result?: T): void;
}

export interface AsyncResultIterator<T, R, E = Error> {
    (item: T, callback: AsyncResultCallback<R, E>): void;
}
export interface AsyncResultIteratorPromise<T, R> {
    (item: T): Promise<R>;
}

declare function mapLimit<T, R, E = Error>(
    arr: T[],
    limit: number,
    iterator:  AsyncResultIteratorPromise<T, R> | AsyncResultIterator<T, R, E>,
): Promise<R[]>;

mapLimit([1,2,3], 3, async (n) => {
    return n ** 2;
});

πŸ™ Actual behavior

The type of n in the mapLimit callback is inferred as any:

Parameter 'n' implicitly has an 'any' type. (7006)

πŸ™‚ Expected behavior

I would expect the type of n to be inferred as number.

Additional information about the issue

This example is based on the types for the async package:

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/b9820410f85f259cbad6065d8cb6f23f403109ac/types/async/index.d.ts#L321-L325

Note that if the type for iterator in mapLimit is changed to either just AsyncResultIteratorPromise<T, R> or just AsyncResultIterator<T, R, E> (that is, no longer a union type), things work as expected and n has type number.

I found a very old discussion of what looks to be the same issue in the DefinitelyTyped repo: DefinitelyTyped/DefinitelyTyped#24297. The issue described there is exactly the one I'm facing. One commenter claimed that things worked correctly, and another commenter claimed that changing the way that async was imported had some effect? Neither of those sounds plausible to me.

I found some issues that may describe the same or a similar problem:

However, my knowledge of TypeScript internals/terminology isn't strong enough to say for sure that this isn't a novel issue I'm facing. If this is in fact a duplicate, please close it as such and I'll add this example to the relevant issue. Thank you!

@Andarist
Copy link
Contributor

Simpler repro:

function test<T>(
  arr: T[],
  cb: ((item: T) => void) | ((item: T, extra: unknown) => void),
) {}

test([1, 2, 3], (item) => {});

Currently, getContextualSignature returns undefined in this situation because the 2 signatures that are present here don't pass the compareSignaturesIdentical check in that function

@RyanCavanaugh RyanCavanaugh added Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases labels Jul 26, 2024
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Jul 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants