keyof operator corrupted if object which contains call signature passed to generic function.

[brn]

TypeScript Version: 2.6.0-dev.20170922

Code

function test<T>(target: T, name: keyof T) {}

test({ a: 1, b: 2, c: 3, d() {} }, "d");

but below code worked.

function test<T>(target: T, name: keyof T) {}

test({ a: 1, b: 2, c: 3, d: () => {} }, "d");

Probably keyof operator can't iterate over properties if object contains method signature passed as function arguments.
And then, below code worked expectedly.

function test<T>(target: T): keyof T {
  return "a" as any;
}

const k = test({ a: 1, b: 2, c: 3, d() {} });
// typeof k = 'a' | 'b' | 'c' | 'd'

Expected behavior:

Compiled

Actual behavior:

Error occured.
error TS2345: Argument of type '"d"' is not assignable to parameter of type 'never'.

I think this issue caused by getPropertiesOfObjectType of checker.ts not return callSignatures.

[sandersn]

The root problem is that contextual typing is interfering with type inference. During type inference, the compiler sees that the object literal contains a method d() { } that is contextually typed, so it might be affected by other arguments. Consider the functional-like example below:

declare function f(n: number): number;
declare function two<T>(first: T, second: T): void;
two(n => n + 1, f);

This example is silly but it's similar in structure to things like pipe or apply or compose. The type inference algorithm notices that n => n + 1 is contextually typed, so it defers inference to a second round. Then it picks up a good inference from f, and can successfully fix the type of n: number and look for inferences from n => n + 1. (In this example it won't find anything new since it's just trying to infer to T, but it might if you were inferring to (t: T) => U or something.)

The problem is that the next inference is to keyof T, which only produces inferences for things like keyof U ==> keyof T. "d" ==> keyof T just does nothing. So the inferred type argument is {}, keyof {} is never (the empty string literal union), and "d" is not assignable to never.

The next question is why your last example succeeds. I'll go look at that next, and maybe it will give me some ideas for how to work around the contextual typing problem in the first example.

[sandersn]

The second example works because the array function has no contextually typable parameters. If you add a parameter, it will also fail. Both these calls fail:

declare function badInference<T>(target: T, name: keyof T): void;
badInference({ a: 1, b: 2, c: 3, d(n) { return n } }, "d");
badInference({ a: 1, b: 2, c: 3, d: n => n }, "d");

[sandersn]

The reason that the last example works while the first does not is that type inference has a loop that progressively tries to infer from more and more contextually typed arguments. The catch is that the loop stop whenever an error occurs. So the last example looks like this:

badInference({ a: 1, b: 2, c: 3, d(n) { return n } });

1. Skip the first (and only) argument. Infer T={}.
2. Is { a: 1, b: 2, ...} assignable to {}? Yes.
3. Are there skipped arguments? Yes.
4. Reinstate the first argument. Infer T={ a: number, b: number, c: number, d: (n: any) => any }
5. Is { a: 1, b: 2, ...} assignable to { a: number, b: number, c: number, d: (n: any) => any }? Yes.
6. Succeed.

The first example goes like this:

1. Skip the first argument.
2. Infer from the second argument "d" to keyof T. No inferences, so infer T={} again.
3. Is { a: 1, b: 2, ...} assignable to {}? Yes. Is "d" assignable to keyof {}. No.
4. Fail and report error.

This is a design limitation of the inference algorithm combined with contextual typing. I'll think about whether it's possible to fix it.

[sandersn]

I found a small ad-hoc fix. It's up at #19159, but I need @ahejlsberg to look at it since overload resolution and type inference are very complicated. :)