Why can tasks (or streams) throw(), but not return()?

[domenic]

Synchronous generators, per a couple TC39 meetings ago, can return() in addition to throw()ing. Why can't tasks, or streams? It says "the observer may unsubscribe with an error" for a task's throw(); why can't they unsubscribe without an error?

[kriskowal]

This asymmetry has been bothering me as well, but I have been asking myself the opposite question, what does it mean for the consumer to return? Perhaps that question can be answered if I study what it means for generators now. I am skeptical if it means that the yield behaves like a return.

[domenic]

Well, from what I can tell, (sync) generators are a complete free-for-all in terms of capabilities vended; the consumer can do the exact same set of operations that the producer can, just using methods instead of syntax.

[kriskowal]

Yeah, sync and async generator objects should probably be symmetric, and they would be completely symmetric if we renamed "next" to "yield" (not going to happen, but perhaps for the purposes of a completely ivory tower blog…)

[kriskowal]

I added return to the iterator interface in both the article and the stream sketch, but perhaps you or @andywingo can do me a favor and illuminate what happens when you iterator.return(10) on a generator that is paused on a yield. Throwing on a yield makes sense to me. Does it turn the yield into a return, unravelling the stack and forcing the generator to terminate with the given return value? When the stack passes through a try/catch, I assume it bypasses the catch, but if it passes through a try/finally, I presume it executes the finally. If the finally has a yield or return, I presume it overrides the intended return 10 iteration, leaving the generator in a resumable state if it yields.

[wingo]

WRT your question, I don't really know yet what return means, as it hasn't reached the spec yet. I think your idea is right but who knows; specification is magical.