Async generator functions plus generics cause confusing errors about Awaited on return

[kristian-elder]

Bug Report

🔎 Search Terms

"asyncgenerator"
"async generator awaited"

🕗 Version & Regression Information

When checking the Typescript playground, the behaviour exists in 4.5.5 but not 4.4.4 and is still present in Nightly as of 5 May 2022.

⏯ Playground Link

Playground link with relevant code

💻 Code

async function* test<T, TReturn, TNext>(): AsyncGenerator<T, TReturn, TNext> {
  // const foo: Awaited<TReturn> = null as any // this would one be accepted as the return type in more recent typescript
  const bar: TReturn = null as any // Although this matches TReturn exactly, it is not accepted as a return value
  return bar
}

🙁 Actual behavior

Typescript rejects a return from an async generator that matches the return type argument from a generic AsyncGenerator, instead expecting an Awaited. This is confusing when creating generic helper methods dealing with generators, and also unexpected as presumably an async generator should be allowed to return both a T and Promise.

🙂 Expected behavior

Returning with a value matching the generic return type from AsyncGenerator should be accepted as value.

[andrewbranch]

@rbuckton why is this? I understand why the IteratorResult would be of Awaited<TReturn> but not why the return value inside would have to be assignable to it.

[rbuckton]

Hmm. This shouldn't be an error since an async generator will adopt the return value whether or not it's a Promise. In other words, the following works but you shouldn't need the await:

async function* test<T, TReturn, TNext>(): AsyncGenerator<T, TReturn, TNext> {
  const bar: TReturn = null as any
  return await bar
}

[Andarist]

I took a moment to analyze this as it seemed to be pretty interesting.

At first, I thought that unwrapReturnType is somewhat broken because Awaited<T> is just left as-is after passing through it (so it isn't really unwrapped). And arguably - it could probably be unwrapped here. However, I'm unsure how this would affect other things, but IIRC a simple & incorrect unwrapping, type.aliasTypeArguments[0], performed in the getAwaitedTypeNoAlias didn't break much. The only difference was the error reported here:

TypeScript/tests/baselines/reference/doNotElaborateAssignabilityToTypeParameters.errors.txt

Line 11 in 53343dd

!!! error TS2322: 'T' could be instantiated with an arbitrary type which could be unrelated to 'Yadda | Awaited<T>'.

It changed from:

Type 'Yadda | Awaited<T>' is not assignable to type 'T'.
  'T' could be instantiated with an arbitrary type which could be unrelated to 'Yadda | Awaited<T>'.

to

Type 'T | Yadda' is not assignable to type 'T'.
  'T' could be instantiated with an arbitrary type which could be unrelated to 'T | Yadda'.

I don't think this was an incorrect change of the error fixture here but this kind of unwrapping definitely missed a lot of cases as it didn't actually instantiate this conditional type.

I think that instantiating it there, within getAwaitedTypeNoAlias, would probably yield good results and that it might be worth exploring. // EDIT: this is impossible, the type argument is generic after all

However, I took a step back and analyzed how this compares to simple async functions and stuff. So the difference is that with async functions the return type of Promise<T> is indeed "unwrapped" and we operate on T as the "target" type. We can also try the reverse situation in the context of a simple async function - trying to assign Awaited<T> to T. This works because Awaited<T> is a "source" type in this scenario and structuredTypeRelatedTo can handle this situation (trying to assign a source conditional type to a target type param).

The problem is that the reverse isn't true - structuredTypeRelatedTo isn't capable of assessing that something is assignable to a target conditional type here. And this is what happens in the case of async generator (trying to assign T to Awaited<T>). A successful assignment can currently only be performed when the target type is conditional when if !c.root.inferTypeParameters && !isDistributionDependent(c.root) and this conditional type is distribution dependent (and it has to be).

So... I could try to instantiate this specific conditional type in getAwaitedTypeNoAlias and it would probably work. And maybe this is even worth doing as optimization or something, but a better solution (conceptually) would be to improve the algorithm around assignability when a target type is conditional. If you have any thoughts on how the improved algorithm could work - I could try to take a stab on this, but I'm incapable of figuring this out on my own.

Let me know what you think about this.