Constrain return statements in generator functions.

[brandonbloom]

Generator functions should constrain their return types to match the result type of the return method on their declared Iterator subtype.

This is deeply related to #2983 - but I wanted to call it out separately because it's a small subset of the total changes required to completely support iterators as coroutines.

TypeScript Version: 2.5.2

Code

interface Iterator<T> {
    next(value?: any): IteratorResult<T>;
    return?(value?: any): IteratorResult<any>; // changed to represent current reality.
    throw?(e?: any): IteratorResult<T>;
}

type Effect = { op: string };

interface Coroutine extends Iterator<Effect> {
    // Override return to constrain return values to Effect.
    return?(value?: any): IteratorResult<Effect>;
}

interface Process extends Coroutine {
    [Symbol.iterator](): Coroutine;
}


let f = function* (): Process {
    yield { op: 'tick' }; // OK.
    yield 1; // Expected error: Not an effect.
    return 1; // Unexpected lack of error! Not an Effect.
}

[agentcooper]

@mhegazy @RyanCavanaugh @rbuckton can you please take a look at #23571?

[falsandtru]

I think generator function's return type is not constrained by iterator type. At least that return type can be undefined.

[mhegazy]

I do not think this is the correct solution to this issues. the underlying issue here is that the generator has two possible return states, and each has a possibly different type. each type is witnessed in different use case (done: true vs done: false). The solution thus is not to restrict return to fit the yielded type, but rather to correctly model the generator interface.

#11375 tracks correctly modelling the generator interface and correctly inferring the the three type, 1. yielded values, 2, returned values, and 3. yield expression type (input to next).

[mhegazy]

closing in favor of #11375.