Typescript fails to infer return type for function under some circumstances (related to `typeof` operator)

[ashtonsix]

Bug Report

🔎 Search Terms

typeof, generic, return type, inference

🕗 Version & Regression Information

Tested with TypeScript 4.6.2 only

⏯ Playground Link

Playground link with relevant code (includes a few extra variations on the issue)

💻 Code

let value = 1

function decorate<O extends any>(fn: (first: {value: typeof value}) => O) {
    return (): O => fn({value})
}
let f = decorate(({value}) => 5)

🙁 Actual behavior

The type of f is () => unknown.

🙂 Expected behavior

The type of f should be () => number. If typeof value (from the code example) is replaced with number, then the code behaves as expected. The code also behaves as expected when first is not an object.

[gabritto]

tl;dr: some implementation details of the checker combine to make this inference fail, mainly because the checker believes that type parameter O could be referenced in type {value: typeof value}. A more technical description of what happens in the checker follows.

I did an investigation of why the inference fails for the function decorate<O extends any>(fn: (first: {value: typeof value}) => O).
If I understand correctly, the problem happens because, when we try to infer a type argument for type parameter O in the call decorate(({value}) => 5), we proceed to check what the type of the argument ({value}) => 5 is.

When checking the type of ({value}) => 5, we see that it is contextually typed by the type of fn: (first: {value: typeof value}) => O (because an arrow function passed as argument to some other function is contextually typed by the expected parameter type from the other function) . More specifically, we see that the parameter of ({value}) => 5, i.e. {value}, is contextually typed by the type of {value: typeof value}.

We then need to get the type of the contextual parameter {value: typeof value}, to assign this type to the parameter {value}.
When we try to get the type of {value: typeof value}, we need to check if there are type parameters in scope that could influence this type, and instantiate those type parameters. So we try to compute the type parameters of {value: typeof value}, and we conclude that O is a type parameter that could possibly be referenced in {value: typeof value}.
Once we think that O is a type parameter that might be referenced in {value: typeof value}, we need to instantiate O. So we instantiate it with unknown, because at this point, unknown is the best inference candidate for instantiating O we have so far (remember that this all is happening while we're trying to infer a better type for O).
Now, because we have instantiated O, and used the resulting type for another type computation, i.e. assigning a contextual type to ({value}) => 5, we fix the type of O as unknown, meaning that we cannot change the instantiation for O further in the inference process, because we already used the unknown instantiation to compute something else.

There are also some additional details: the case in the extended examples of function decorateB<O extends any>(fn: (first: typeof value) => O) succeeds because the type of first is not an object, so the symbol for first is not transient, so we don't try to instantiate it like described above. Same for the type First = {value: typeof value}; function decorateD<O extends any>(fn: (first: First) => O) case: using an alias for the type of first means no transient symbol, and no instantiation for O like above.
The function decorateC<O extends any>(fn: (first: {value: number}) => O) case succeeds because, when trying to instantiate O to get the type of {value: number}, we can tell that O couldn't be referenced in {value: number}, so we don't fix the instantiation of O and can perform further inference.

Now, I'm not sure how we could fix this problem, especially since it's been seemingly present for a long time in our checker. For a person looking at what is going on, it is clear that O is not referenced in first: {value: typeof value}, and even that we don't really need to instantiate O to get the parameter type of first: {value: typeof value}. But, given the way the checker works, I'm not sure what we could change to fix this. And, since the problem is that our inference fails to infer more specific types, and not e.g. something resulting in an error message, we can't even make it clear to users what exactly is happening.
@ahejlsberg do you have any ideas on how we could fix this?

[ahejlsberg]

Yeah, this one is tricky. In getObjectTypeInstantiation we want to share object type instantiations to the largest extent possible. To facilitate this, we determine which type parameters are in scope and referenced by the object type. We then create keys from the type arguments supplied for the referenced type parameters and cache instantiations based on those keys.

Now, the logic for determining whether a type parameter is referenced in an object type simply involves a walk of the AST of the object type to examine type references. However, when we see a typeof xxx type query it may be the case that the type of xxx depends on the particular type parameter. In fact, it is quite hard to prove that it doesn't. Therefore, when an object type contains type queries, we consider it to reference all in-scope type parameters.

We could potentially attempt to analyze type queries a little deeper. In fact, when the leftmost identifier in a type query references an identifier whose declaration is outside the scope of a particular type parameter, it is safe to say the type query doesn't depend on that type parameter.