Preserve ordered yield types when no logic is involved

[sdegutis]

Suggestion

🔍 Search Terms

yield ordered return types

✅ Viability 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, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Make types more definite for each yielded return value in a generator function

See also https://stackoverflow.com/questions/66538431/function-chain-factory-in-typescript-preserving-input-output-types

📃 Motivating Example

Right now, if I do this:

function* work() {
  yield 1;
  yield 'test';
  return [123];
}

Right now this gives:

const g = work();
g.next().value  // string | number | number[]
g.next().value  // string | number | number[]
g.next().value  // string | number | number[]

But since there's no logic/branching/etc, it would be more helpful to me to have:

const g = work();
g.next().value  // number
g.next().value  // string
g.next().value  // number[]

💻 Use Cases

Sometimes I want to use a function generator to represent a series of steps that I want to examine (whether at runtime or during testing, etc) before deciding whether to continue. In other words, I want to break up a function into a series of "pauseable" steps.

[jcalz]

Is this like #32523 and/or #42033?

[RyanCavanaugh]

#42033 looks very close, yes.

[sdegutis]

@RyanCavanaugh I think this one could be a very simple "gateway" implementation for other issues like that one which cover more cases. This might be just enough of a catalyst to justify making the minimal changes to the type system needed to get the ball rolling for other features.

[sdegutis]

@RyanCavanaugh The reason I think so btw is because I saw in #32523 (comment) that it's the missing relationship between TYield and TNext that's the show-stopper, and this feature request is just for the specific use-case when you can clearly see that there's no yields inside any branching/logic, so that you can safely know that it's just a fixed list of types. It might even be possible to use tuple types to achieve this. At which point, the groundwork is laid for the more complex use-cases. Anyway just an idea.

[sdegutis]

Oh. Looks like that issue was talking about the type of the value returned to the yield, not the value returned from the yield. Oops.

[sdegutis]

Honestly I'm not even sure what the use-case is for this anymore. I certainly don't currently have one. Worth closing imo.

[iliaamiri]

@thesoftwarephilosopher

My use-case is that I want to create a minimal array that only has the tuple values and no other methods such as: map, flatMap, forEach, etc.

export type MinimalArray<T, E> = {
  0: E
  1: T
  length: 2
  [Symbol.iterator](): Iterator<E | T> // I can't pass the tuple values here. It will make them a union type. 
}

Let's say I created an object and artificially implemented the [Symbol.iterator]() method myself.

class CustomTuple<T1, T2> {
  private readonly _values: [T1, T2]; // Internal array-like storage for elements

  constructor(first: T1, second: T2) {
    this._values = [first, second];

    // Define properties 0 and 1 to enable indexed access (like a tuple)
    Object.defineProperty(this, '0', {
      value: first,
      enumerable: false,
      writable: false,
    });

    Object.defineProperty(this, '1', {
      value: second,
      enumerable: false,
      writable: false,
    });
  }

  // Length property to match tuple behavior
  length: 2 = 2;

  // Iterator for spreading and iteration
  [Symbol.iterator](): Iterator<T1 | T2> {
    let index = 0;
    return {
      next: (): IteratorResult<T1 | T2> => {
        if (index < this._values.length) {
          return { value: this._values[index++], done: false };
        } else {
          return { value: undefined, done: true };
        }
      },
    };
  }
}

When I destructure it, I get a union type:

const tuple = new CustomTuple(1, "bar")

const [a, b] = tuple
// a -> string | number
// b -> string | number

The nice thing about my CustomTuple is that, I don't see the extra Array API that comes with a regular Array object:

So the user cannot do tuple[0] or tuple[1] either. That's what I want.

---

So, there is no way I can achieve the same result as defining a standard fixed tuple:

const foo = [1, "bar"]

const [a, b] = foo
// a -> number
// b -> string

[kayahr]

Stumbled over the same problem. Having no way to tell TypeScript the number of tuple elements (that's what #42033 is about) doesn't concern me that much. Would be nice to have a fix for this, too, but the more grave problem is that there is no way to have different tuple iterator value types.

There is probably a way to convince Typescript that the class instance is ALSO of type readonly [ number, string ] but then Typescript also thinks the object provides methods like entries which it does not. So any kind of type casting to an array type is a bad idea.

My current "workaround" is basically this (and I don't really like it because it separates TypeScript users from JavaScript users):

export class Test {
    public *[Symbol.iterator](): Iterator<number | string> {
        yield 10;
        yield "hello";
    }

    public destruct(): [ number, string ] {
        return [ ...this ] as [ number, string ];
    }
}

JavaScript users can destruct the object directly:

const [ numVal, strVal ] = new Test()

TypeScript users have to call the destruct method instead to get the correct types:

const [ numVal, strVal ] = new Test().destruct()

Hopefully in the future this no longer necessary and we can describe the iterator type correctly so I can get rid of the destruct method.