Yield return type should be defined by the next argument type in generators

[EmrysMyrddin]

Search Terms

• async runner
• generators type

Suggestion

The 3.6RC is implementing stricter generator type. This is a good first step to model ES6 generators by allowing the definition of both yielded and returned values.

There was a long discussion about this implementation in issue #2983. It has been closed but a use case is still not covered : the async runners like co or redux-saga (or any other lib using generators as co-routines).

In my humble opinion, the last comment about it (#2983 (comment)) is a good starting point. At least, it allows to strictly type a runner implementing async/await behavior.

Examples

There is lot of examples out there since co-routines is a pattern gaining lots of popularity. Even in large application, being able to hook await can be very useful (for cancellation or execution context).

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[EmrysMyrddin]

I'm copying @hallettj comment here :

For the async task runner / coroutine / redux-saga use cases I also think it would be very helpful to be able to describe the type for TNext in terms of the specific type of the previously-yielded value. Basically what @Alxandr said, but I think it would be useful to express a mapping using a function type: the argument position provides spot to bind a variable for the type of the last yielded value. For example adapting @treybrisbane's example of a generator that yields promises:

function* c(): Generator<Promise<any>, string, <T>(yielded: Promise<T>) => T> {
  const aNumber = yield asyncAddTwo(4); // asyncAddTwo is of type `(n: number) => Promise<number>`
  const aString = yield asyncToString(aNumber * 2); // asyncToString is of type `(n: number) => Promise<string>`

  return `Result was ${aString}`;
}

Instead of providing a type for TNext this formulation provides the mapping <T>(yielded: Promise<T>) => T. The mapping might alternatively be an intersection of function types to specify different types for the next value depending on the yielded value.

I suggest that if the type of the last yielded value does not match the input type for the mapping then the type for the next value should implicitly be never.

(I apologize if I am repeating a suggestion that has already been made. I tried to scan the discussion so far, but I might have overlooked something.)

[falsandtru]

See #32523

[EmrysMyrddin]

@falsandtru Thanks, didn't found it in the issue search...
I close this issue.