Generator functions may not return `IteratorObject`

[laverdet]

🔎 Search Terms

If you have a generator function which a declared type of IteratorObject<T> and an implicit return, you receive the error "A function whose declared type is neither 'undefined', 'void', nor 'any' must return a value. ts(2355)". I would expect us to be able to return these objects, since they adhere to the IteratorObject<T, unknown, unknown> interface.

This seems semi-related to the TypeScript 5.1 announcement easier implicit returns for undefined returning functions.

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about [Iterators and Generators]

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/PTAEBUAsEsGdTqA9gawFADMCuA7AxgC7RI6gBUGSSAFAJQBcoAkgQKYBOAhgUuwPIAjAFatCAHhxYAtgI4A+UAG80oUAE9orADYATUAEYA3CtDtWBLOxzGAvmjQhQAQVDZ8REqADukJLFagOqJanGZ6BGoADgGIOKzQBJAcoADkuEEY0HE6KQA0qQBuSNA5+Ti8qZw4aimgUliwBKbmlqScoAWcWlisAHQEsNQATADMAKxjtJi4hMSkZAKhdIwsHNy8giLikjLySiYa2npGaHYOYE5asEj5qNPuc+TmeMvMbFw8-MKiBBLSsuwFMpVD5oFoAtQCOwerR1JpdAZbEA

💻 Code

// This is ok
function *foo(): IteratorObject<number> {
  yield 1;
  return;
}

// A function whose declared type is neither 'undefined', 'void', nor 'any' must return a value.ts(2355)
function *bar(): IteratorObject<number> {
  yield 1;
}

// Also, ok
function *etc(): IteratorObject<number> {
  while (true) yield 1;
}

🙁 Actual behavior

"A function whose declared type is neither 'undefined', 'void', nor 'any' must return a value.ts(2355)"

🙂 Expected behavior

This should be allowed.

Additional information about the issue

No response

[jcalz]

(Not a TS team member) Implicit returns conform to unknown but it's currently considered an error to write function foo(): unknown {}. The behavior with IteratorObject for generator functions looks consistent with that. TS is expecting a return type like IteratorObject<number, void> and not IteratorObject<number, unknown> here. If you change it to use void then the error goes away. So this doesn't look like a bug to me (even though I personally would rather TS not complain here or in the case I show above).

Maybe this should be reworded as a feature request that IteratorObject's default second type argument be void instead of unknown?

[nmain]

This also "works" if you use Iterable<T> as your return type because instead of TReturn = unknown, TNext = unknown, Iterable defaults to TReturn = any, TNext = any.

[laverdet]

Maybe TReturn should default to void instead of unknown.

[Renegade334]

This discussion seems a bit XY - there is already a dedicated return type for generator functions, that can be used in return annotations, whose default TReturn deliberately facilitates this syntax?

function *bar(): Generator<number> {
  yield 1;
}

[nmain]

deliberately facilitates

Is that true? It seems to be mostly happenstance. Why should the defaults be any on Generator<> and Iterable<> but unknown on IteratorObject<>?

[laverdet]

The point about Generator<T> is reasonable. I make very heavy use of generator functions in my software, usually just to create simple iterables instead of returning arrays which will only be walked a single time. I've always found the Generator<T, R, N> interface too chaotic in my log messages, due to the three template parameters. So for that reason I "downcast" my results to Iterator<T>. Now with built-in iterators it means I am losing functionality.

So perhaps the best answer to this issue is to create an interface extending Generator for my needs.

I still think it's worth considering void as a default for TReturn on IteratorObject, but understand that the ship may have sailed already.

[RyanCavanaugh]

Changing the type parameter default would be a pretty big change - all existing spellings of IteratorObject<X> would suddenly completely change meaning. This would definitely break a lot of people, but the upside isn't super clear; as noted there are many ways out of this.