Incorrect typing for iterables in lib

Search Terms:

iterable return type
asynciterable return type

Related Issues:

https://github.com/Microsoft/TypeScript/issues/2983 - describes how the iterables types are not inferred correctly for generators. Fixing this current issue would be a step towards making that issue resolvable as well.

The Problem

The type definitions for iterable and asynciterable do not match the specification.

According to the specification, when IteratorResult has done: true, the value is the return value of the iterator. This is not the same type as an element of the iterator. When implementing an iterator or async iterator "by hand", you get spurious type errors. For example:

const counter = (offset = 0, limit = 10) => {
  let x = 0;
  const a: AsyncIterator<number> = {
    next: async () => {
      if (x < 5) {
        x++;
        return { x, done: false };
      }
      return { done: true };
    },
  };
};

export default counter;

Gives errors:

src/testing/temp.ts:4:5 - error TS2322: Type '() => Promise<{ x: number; done: false; } | { done: true; x?: undefined; }>' is not assignable to type '(value?: any) => Promise<IteratorResult<number>>'.
  Type 'Promise<{ x: number; done: false; } | { done: true; x?: undefined; }>' is not assignable to type 'Promise<IteratorResult<number>>'.
    Type '{ x: number; done: false; } | { done: true; x?: undefined; }' is not assignable to type 'IteratorResult<number>'.
      Property 'value' is missing in type '{ x: number; done: false; }' but required in type 'IteratorResult<number>'.

4     next: async () => {
      ~~~~

Thus, the types for iterables and async iterables should look more like this:

interface IteratorValueResult<T> {
    done?: false;
    value: T;
}
interface IteratorReturnResult<T = undefined> {
    done: true;
    value: T;
}
type IteratorResult<T, U = undefined> = IteratorValueResult<T> | IteratorReturnResult<U>;

interface Iterator<T, U = undefined> {
    next(value?: any): IteratorResult<T, U>;
    return?(value?: any): IteratorResult<T, U>;
    throw?(e?: any): IteratorResult<T, U>;
}

interface Iterable<T, U = undefined> {
    [Symbol.iterator](): Iterator<T, U>;
}

interface IterableIterator<T, U = undefined> extends Iterator<T, U> {
    [Symbol.iterator](): IterableIterator<T, U>;
}

and

interface AsyncIterator<T, U = undefined, NextArg = undefined> {
    // the type of the argument to next (if any) depends on the specific async iterator
    next(value?: NextArg): Promise<IteratorResult<T, U>>;
    // return should give an iterator result with done: true` and the passed value (if any) as the value
    return?<R = undefined>(value: R): Promise<IteratorReturnResult<R>>;
    // throw should return a rejected promise with the given argument as the error, or return an iterator result with done: true
    throw?(e: any): Promise<IteratorReturnResult<undefined>>;
}

interface AsyncIterable<T, U = undefined, NextArg = undefined> {
    [Symbol.asyncIterator](): AsyncIterator<T, U, NextArg>;
}

interface AsyncIterableIterator<T, U = undefined, NextArg = undefined> extends AsyncIterator<T, U> {
    [Symbol.asyncIterator](): AsyncIterableIterator<T, U, NextArg>;
}

This should allow typescript to correctly infer that value is not required when done: true. For generators that do have a distinct return type from their yield type, they will be able to typecheck without spurious errors.

If the above definitions are acceptable to the maintainers I can prepare a PR to update the type definitions.

References

• Iterator Interface
• AsyncIterator Interface
• IteratorResult Interface