Repository navigation
Change in behavior around keyof any inference #29765
Description
TypeScript Version: 3.4.0-dev.20190202
Search Terms: any, array, argument
Code
function getProps<T, K extends keyof T>(obj: T, list: K[]): Pick<T, K> {
return {} as any;
}
const myAny: any = {};
// TS 3.2.2 - getProps returns Pick<any, "foo" | "bar">
// TS 3.4 - getProps returns Pick<any, "foo" | "bar">
const o1 = getProps(myAny, ['foo', 'bar']);
// TS 3.2.2 - getProps returns Pick<any, "foo" | "bar">
// TS 3.4 - getProps returns Pick<any, string>
// └ 🚨 Type 'Pick<any, string>' is missing the following properties
// from type '{ foo: any; bar: any; }': foo, bar [2739]
const o2: { foo: any; bar: any } = getProps(myAny, ['foo', 'bar']);Expected behavior:
I expect o2 above to type-check successfully in 3.4
Actual behavior:
Playground Link: NOTE: does not demonstrate the reported behavior, since it's only reproducible in recent 3.4 nightly builds
Activity
ahejlsberg commentedon Feb 6, 2019
Looks like this is an effect of #29478. Previously we'd make no inferences from the return type in the second example, but now we infer from
{ foo: any; bar: any }toPick<T, K>. This produces an inference forK, but not forTbecausePick<T, K>isn't a homomorphic mapped type (it's partially homomorphic in that it only maps a subset of the properties). Because we have no candidates forT, we end up with an inference of{}from the return type, which then causes us to reduce our inference forKtonever. We then proceed with this rather useless contextual type which ends up making matters worse rather than better.Looks like we need to do better when inferring to
Pick<T, K>. I will see what we can do.