Options for specifying generator behavior

[codehag]

Hi Folks,

This discussion began in #86.

Jason just presented this slide deck: https://docs.google.com/presentation/d/1QVW_d4lpiFQ5X5czGWq0VMRN9cMLIGpt888TQoyFWpg/edit#slide=id.p

And we had these example write ups: https://gist.github.com/jorendorff/35504c2553170be98fc2810ccf60c608

We have 3 options summarized here

1. Plain generator with no forwarding for throw and return
2. custom object which forwards throw, return and next with arguments to the original iterator
3. generator which handles forwarding

Let's continue the discussion we had in the call here, and see if we can get to a solution.

[bakkot]

Re: 3, it would be a function which does validation and then uses a spec-internal generator, right? Doing validation when invoked rather than .next seems important to me.

I'm OK with 2 or 3. I lean towards 2, but not strongly.

[jorendorff]

Re: 3, it would be a function which does validation and then uses a spec-internal generator, right?

Yes, that's right.

Doing validation when invoked rather than .next seems important to me.

I agree.

[michaelficarra]

I'm OK with 2 or 3. I lean towards 2, but not strongly.

Same.

[jorendorff]

@michaelficarra I'm going to meet with @ljharb and @bakkot, and I hope @devsnek at 2PM Pacific time today to discuss this. Please join us if you can; we'll gather in #tc39-delegates on IRC, then probably meet on Zoom.

[michaelficarra]

K I'll be there.

[jorendorff]

At this meeting, we settled on a hybrid approach. Not set in stone, but my understanding is that everyone agrees this is the direction we want to go:

1. User visible behavior:

   • All iterator helpers will inherit from a new %HelperIteratorPrototype% (maybe not named that) whose [[Prototype]] is Iterator.prototype.
   • This new prototype will have its own .next(), .return(), and .throw() methods.
   • There won't be distinct prototype objects for map vs. filter vs. flatMap, etc. (I'm not 100% sure we agreed on this) (confirmed, we agreed there won't be)
   • .return() and .throw() will be passed to source iterators (for example, iter.map(fn).return(0) results in a call to iter.return(0)).
   • Iterator helper objects are otherwise pretty much opaque.

2. Specification details (none of this is set in stone, but this is the plan for now):

   • The specification text will be, broadly speaking, generator-like.
   • Each iterator helper object will have an internal slot that contains a generator-like algorithm (an abstract closure) with "Yield" steps, something like the %SyncMap% sketch @devsnek posted in Definition of 'prelude steps' for generator function algorithms #86.
   • We didn't discuss how to handle re-entrancy in detail, but I think the idea is to either implement what generators do, or factor it out and use the same machinery for both iterator helpers and generators.
   • I'll look at what would happen if we applied the same generator-esque approach to existing iterators already in the standard, like Array Iterators.

[Bergmaier]

Thanks for the update @jorendorff!

There won't be distinct prototype objects for map vs. filter vs. flatMap, etc.

I'm a bit disappointed by that (it's a user-visible distinction from option 2), could you explain the arguments for this?

I would have thought it would be possible to cut down the spec text for multiple objects in the same manner as for The TypedArray Constructors, their properties, and their prototype objects. This would also allow using the new spec syntax for the existing string/array/map/set iterators.

[ljharb]

@Bergmaier one motivation is to ensure that it's not automatically an observable (and thus breaking) change to add a .map, for example, on to the end of a returned iterator.

There doesn't need to be any correlation between "keeping the spec text small" and "the number of user-visible objects".

[codehag]

Closed by #112