Argument becomes implicit any when a void-returning overload follows a non-void-returning signature

[JoshuaKGoldberg]

Bug Report

🔎 Search Terms

overload argument type signature

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about overloads (and Calling an overloaded function should resolve to best match, not first #48077)

⏯ Playground Link

Playground link with relevant code

💻 Code

declare const it: {
    (test: () => Promise<void>): void;
    (test: (input: string) => void): void;
}

it((input) => {
    input.toUpperCase();
});

it(async () => {
    // ..
});

🙁 Actual behavior

Error: Parameter 'input' implicitly has an 'any' type.

🙂 Expected behavior

No type error. The input parameter is type string and should be resolved as such.

For more context, see DefinitelyTyped/DefinitelyTyped#59075.

[MartinJohns]

I think this is due to: https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes#implicit-any-error-raised-for-un-annotated-callback-arguments-with-no-matching-overload-arguments

Is the first overload really needed? The code will behave the same without it.

[JoshuaKGoldberg]

I think the overloads are needed -- it's either them or an overly long and confusing conditional generic type. The test function can either take in an input or return a Promise. Adjusting the snippet a little to look more like the Mocha types [playground link]:

declare const it: {
    (test: () => Promise<void>): void;
    (test: (done: () => void) => void): void;
}

it((done) => {
    done();
});

it(async () => {
    // ...
});

// @ts-expect-error
it(async (done) => {
    done();
});

I.e. you can't provide an async function that also takes in & calls a done parameter.

[fatcerberus]

Assuming the inference worked, you wouldn't get the expected error on the third call (the only reason it's an error now is because it's an implicit any, like the first call), because it would still match the second overload, per https://github.com/microsoft/TypeScript/wiki/FAQ#why-are-functions-returning-non-void-assignable-to-function-returning-void:

declare const it: {
    (test: () => Promise<void>): void;
    (test: (done: () => void) => void): void;
}

it((done: () => void) => {
    done();
});

it(async () => {
    // ...
});

it(async (done: () => void) => {
    done();
});

Any return type is assignable to a return type of void, including promises. And you couldn't prevent this at runtime either because you have no way to know that the user passed in an async function without actually calling it and observing its return value.

[JoshuaKGoldberg]

the only reason it's an error now is because it's an implicit any, like the first call

Ha, that's fair.

But I think this issue is still valid, that the becoming an implicit any is an undesirable behavior (dating back a while) because now there's no way to accurately represent the Mocha types.

[fatcerberus]

A bit of a tangent but () => void accepting any return type is usually desirable (see FAQ link above), but I do sometimes wish we could write () => undefined for the few cases where you really want to exclude value returns and not then be forced to write an explicit return undefined;.

[RyanCavanaugh]

I'm not quite sure what can be done here. Overload resolution behavior is extremely baked-in and it's going to be tough to change it. PRs that don't break other stuff are welcome 😅

[JoshuaKGoldberg]

Hmm, now that #29374 is in I was looking forward to making another multi-year pull request. Great...!

[fatcerberus]

@RyanCavanaugh I thought this issue wasn’t about overload resolution, so much as contextual typing of callback parameters failing in the mere presence of overloads.

[RyanCavanaugh]

The problem is that we assign a contextual type during overload resolution, and don't have an acceptable way to "undo" that. Prior attempts to fix this have failed for one reason or another.

See also #11936