Generics, overloaded functions, and objects interact inconsistently

[georgewfraser]

Type inference exhibits strange behavior when you have an overloaded function with a generic that takes an object as an argument:

// A function that extracts the values from an object
declare function values<T>(object: { [key: number]: T }): T[];
declare function values<T>(object: { [key: string]: T }): T[];

// A type with a member called 'a'
interface MemberA {
    a: number;
}

// OK
declare var numberObject: { [key: number]: MemberA };
values(numberObject).map(value => value.a);

// Error, infers value : {}
declare var stringObject: { [key: string]: MemberA };
values(stringObject).map(value => value.a);

It seems to be just choosing the first overload.

[ahejlsberg]

That is odd, I agree. The problem appears to be the way in which type inference interacts with assignability and overload resolution. We make inferences from index signatures only when the index signature kinds match (section 3.8.6 in spec), but we consider both string and numeric index signatures to be assignable to numeric index signatures with compatible types (section 3.8.4 in spec). The net outcome is that in your example that generates an error, we infer {} for T in the first overload (because the signature kinds are different) and then we subsequently pick the first overload because [key: string]: MemberA is assignable to [key: number]: T.

I think we need to change the inference rules to allow inferences to be made from both string and numeric index signatures to index signatures such that inference and assignability line up.

[JsonFreeman]

Yes, I agree with @ahejlsberg's solution here. In general, the type argument inference relation should mirror the assignability relation as closely as possible.

[ahejlsberg]

Changing to spec issue. Section 3.8.6 needs to be updated to reflect that we now make inferences from both string and numeric index signatures to numeric index signatures.

[ahejlsberg]

@georgewfraser Thanks for reporting. Fixed in the new compiler.