Contextual typing does not flow backward through function return types to the function arguments

[drarmstr]

Consider the following case:

class Entry<T> {
    constructor(callback: (v: T) => number) { }
}
interface Widget {
    list: Entry<{ foo: number }>[];
}

var widget: Widget = {
    list: [
        new Entry((v) => v.foo), // Error accessing v.foo
    ]
};

We get a compiler error in the callback accessing v.foo that foo does not exist on type {} since {} is the default type when it is unable to infer the type. However, in this case we know from the Widget definition that T must be typed to {foo:number}. But, it appears TypeScript is not using this as an inference-site to properly determine T.

[RyanCavanaugh]

More simply:

class Entry<T> {
    constructor(callback: (v: T) => number) { }
}
var x: Entry<{foo: number}> = new Entry(v => v.foo);

[RyanCavanaugh]

Let's go even simpler:

function foo<T>(x: (n: T) => T): T { return x(undefined); }
var x: string = foo(p => p.substr(2));

(placeholder since I need to write a longer explanation)

[drarmstr]

@mhegazy, Sorry, what is the implication of the Question tag? Is there a follow-up question for me?

[RyanCavanaugh]

Sorry, I forgot to write the follow-up I alluded to.

After walking through this with the spec, I think the rule we would need to support this is that a function call (or constructor call) contextually typed by T creates an inference site corresponding to the return type of that function or constructor.

That said, it's not clear what runtime semantics this rule corresponds to, or that it wouldn't be an undesirable breaking change.

[johnnyreilly]

It would be fantastic if this could be looked into.

[RyanCavanaugh]

Moving discussion to #11152 which has clearer explanation

[RyanCavanaugh]

I believe this is fixed by #16072