Closed
Description
As of change #2356, the following code gives the correct result in the batch compiler:
declare function f<T>(x: T, y: (p: T) => T, z: (p: T) => T): T;
f(0, x => null, x => x.blahblah);Namely, we infer T to be number, and we get an error on blahblah.
However, there are a few things still wrong:
- The language service does not show the correct result. It shows both x's to be number, but if you hover on f, you will see that it was instantiated to
any, instead ofnumber. - If you add another overload, the wrong type argument gets inferred:
declare function f<T>(x: T, y: (p: T) => T, z: (p: T) => T): T;
declare function f();
f(0, x => null, x => x.blahblah);Now suddenly blahblah is not an error, and the second x is any.
- In theory, if this overload is not assignable, but it has already fixed the type parameter T, and another overload comes along with a type parameter in the same position, that second type parameter will not get fixed. I don't have a good repro for this, but it is certainly a possibility in theory.
All of these issues happen because when a function expression parameter causes a type parameter to get fixed, it only does so if it is affected by the type of that type parameter. I believe the right thing here is that even if a function parameter does not align with the type parameter, it should still fix it. That way, it will fix the type parameter no matter which signature is being visited, or whether this signature has been visited before.