Implicit any issue with overloaded methods

[tinganho]

This code was working for me before but broken in the latest:

class A {
    forEach(callback: (a: number) => void): void
    forEach(callback: (a: number, b: number) => void): void
    forEach(callback: (a: number, b?: number) => void): void {

    }
}

const a = new A();
a.forEach((a, b)=> { // Parameter 'a' and 'b' implicitly has an 'any' type
})

[alitaheri]

I can confirm with 2.1.0-dev.20161029. Seems like it tries to match with only the first overload.

Removing the first overload fixes it. Changing the callback to (a) => {} also fixes this.

[HerringtonDarkholme]

Probably caused by #11905

[mhegazy]

this indeed is caused by the change #11905. we should reconsider our fix there.

[sandersn]

This is actually an improvement — b was (mostly) an unreported implicit any before. In 2.0 (or earlier, all the way back to 1.1) try compiling b.blah() inside the body of the lambda. You won't get an error because b is implicitly any.

Note that

1. The playground gives the type of b as number, so there's an additional bug in the language service.
2. The anys are a limitation of the current compiler design, which fixes types while resolving the first overload, which in this case is too short. Previously the types were incorrect, now they're not available at all.

The correct fix is to reverse the order of the overloads or to get rid of the overloads entirely. They are technically redundant but are probably useful as documentation.

[tinganho]

which fixes types while resolving the first overload, which in this case is too short

@sandersn Why do you need to fix the type on the first overload? And not just choose the overload that "fits"? In my example, the second overload should clearly be used for 2 argument callbacks.

I'm pretty sure though, that previous types where not typed any, at least not on my real world application. I'm also getting the error, when defining a test with Mocha testing framework(this one I'm pretty sure it was not typed as any):

it(testName, (done) => { // error 'done' is implicitly typed as any
})

[sandersn]

@Andy-MS actually fixed jasmine.d.ts this morning to work with the updated compiler. The core limitation, since TypeScript 1.1, is that the compiler will only assign types to any expression once. This gives, unfortunately, extremely subtle semantics.

Normally this is fine, but overload resolution changes the contextual type as it tries each overload in order, so you can observe the effect of this limitation. I don't think there's a reasonable way to check overloads besides checking the arguments against each overload in turn. For example, these single-argument functions:

declare function f((x: number, y: number, z: number) => string): void;
declare function f((x: string, y: string) => string): void;
f(x => x);

Even when there's something that clearly makes an overload unsuitable for an argument, it may be nested deep in the argument or parameter type. So I think it's better to use normal type-checking machinery when possible: just ask whether all arguments are assignable to their respective parameters.

In the future, we might go back and rewrite overload resolution but right now we'd prefer to correctly report implicit-any errors from our limited algorithm instead of silently hiding them.