inference strangeness 6

[zpdDG4gta8XKpMCd]

export interface A<a> {
    value: a;
}

function fn<a>(values: A<a>, value: a) : void {
}

let handlers: A<(value: number) => void>;
fn(handlers, value => alert(value)); // < -- expected value: number, actual value: any

[DanielRosenwasser]

This one looks like a contextual typing bug.

[sandersn]

Interestingly, the type parameter is inferred correctly and therefore the type of fn. Here is a cleaned up example that shows this:

interface Box<T> {
    x: T;
}
declare function f<U>(box: Box<U>, u: U): U;
let handlers: Box<(value: number) => void>;
let z = f(handlers, y => y.length); // expected error: 'length' not in 'number'

z: (value: number) => void as expected. So inference hasn't failed, it just failed to propagate its results to the lambda.

[sandersn]

Working bottom up, I see that U is not instantiated when the contextual type of y => y.length is checked, which scuttles contextual type checking (U becomes {} which has no call signature, hence no contextual type). This is during the second round of inference, because contextually typed things like arrow functions are skipped in the first round.

Of course the first round discovers that Box<(value: number) => void> with the target Box<U> gives U = (value: number) => void. Unfortunately, even though the signature is instantiated with this information during the first round, it's thrown away at the beginning of the second round. This might be incorrect.

I'll try moving the code that re-initialises the signature before the inference loop. But I expect this will break something else.

[sandersn]

Removing the per-loop reset breaks the compiler badly. An alternate approach is figuring out how to get checkDeferredNode to get its contextual type correctly. Right now enough nodes already have type 'any' that it gets the wrong answer too, but I'll see if it's possible to change.

[unional]

Another case (let me know if you want to open a new issue for this):

interface Foo {
  init?: () => void;
}

let x: Foo = getX();
if (x.init) {
  x.init();  // Works fine
  let y = () => {
    x.init(); // Object is possibly 'undefined';
  }
}

[DanielRosenwasser]

@unional that's unrelated to this, and behaving as expected. Control-flow-based type analysis doesn't work across function expressions because the value can change at a different point in time.

[unional]

Ah, I see. Thanks! 😛