Hmm, I'm not sure I follow the rationale here. Just because T is used in an awaited T type constructor somewhere doesn't mean that we want to change inference behavior everywhere for T.

Can you provide a bit more context on what you're trying to accomplish and why?

Is a correct summary that you intend for inference from awaited S to a type parameter T, where T only occurs in awaited T type constructors, to infer S instead of awaited S?

At the end of the day, awaited's main purpose is to give you the right type for the value parameter of the onfulfilled callback of the then method of a Promise (or Promise/A+-compatible promise-like implementation), as that is the only place where a value with that type is actually produced.

Consider this minimal definition for something promise-like:

interface Promise<T> {
  then(onfulfilled: (value: awaited T) => any): any
                     ~~~~~
}

The type of value will be the same for all of the following instantiations:

In addition, awaited shares some of same difficulties as conditional types when it comes to working with the type in expression-space. This is apparent if you look at #37526, since there's no way to resolve a promise with a T when it is instantiated with an awaited T, despite the fact that the resulting value will have the same type. Since both awaited T and T will resolve to awaited T, resolving it with a T should be permitted. However, we don't want to make T assignable to awaited T (or vice versa), so generally we want to unwrap any inference to awaited T to become just T as that's more useful.

It is possible this proposed heuristic may be too loose. In reality we may only want to perform this inference when the awaited T is only referenced as the type of value, above. If that is the case I would welcome suggestions on a better way to enforce that.

Is a correct summary that you intend for inference from awaited S to a type parameter T, where T only occurs in awaited T type constructors, to infer S instead of awaited S?

I believe that would be the case, yes. At least, in cases where the T is produced as a value to expression-space. For example, the finally method returns Promise<T> which would be a reference to T that is not awaited. In addition, the TResult1 type parameter for then uses T as a default without necessarily wrapping it in an awaited.

I did a little experiment where I changed inference between references to the same generic type to always proceed structurally if any type parameters have variances marked unreliable (as is the case with T in Promise<T>). This causes the original example to just work as expected. What's happening in the example is that the new Promise(r => r(a)) is contextually typed by Promise<awaited T>. As we proceed with structural inference, we end up with an awaited (awaited T) for the value parameter in the contextual type, which reduces to awaited T, and we then make the correct inference T.

Do we want inference to proceed structurally for all "unreliable" variances or just cases where awaited is used? I'm happy to close this PR if that turns out to be a better solution.

@rbuckton Just pushed the changes we talked about. We now perform structural type inference for any generic type with a type parameter that occurs in an awaited T type constructor.

Only change in baselines is that we flatten inferences from Promise<Promise<number>> which actually seems desirable.

@typescript-bot perf test
@typescript-bot run dt
@typescript-bot test this
@typescript-bot user test this

Heya @rbuckton, I've started to run the parallelized Definitely Typed test suite on this PR at 70f92ff. You can monitor the build here.

Heya @rbuckton, I've started to run the parallelized community code test suite on this PR at 70f92ff. You can monitor the build here.

Heya @rbuckton, I've started to run the perf test suite on this PR at 70f92ff. You can monitor the build here.

Update: The results are in!

Heya @rbuckton, I've started to run the extended test suite on this PR at 70f92ff. You can monitor the build here.

The user suite test run you requested has finished and failed. I've opened a PR with the baseline diff from master.

@rbuckton
The results of the perf run you requested are in!

This seems to have improved things in vscode: https://github.com/typescript-bot/TypeScript/pull/9/files#diff-0e62d568d28b82cee9e66b2b8fafd290R7, however there seem to be a larger number of errors now in office-ui-fabric (https://github.com/typescript-bot/TypeScript/pull/9/files#diff-976ec9fe54f7b841cd49ec069e0303a9L135), though that may not be related to this change.

Closing this in favor of #37610 for now while we continue to investigate the impact of awaited.