TC39 Delegates
2022-12-09
plaintext logs
prev next
source on github
22:31
<ljharb>
Michael Ficarra snek bakkot: in https://tc39.es/proposal-iterator-helpers/#sec-iteratorprototype.filter step 3.b.iii, if IteratorValue completes abruptly, is that a case of a misbehaving iterator, and thus why we don't take care to close the iterator?
22:49
<ljharb>
i'm asking in particular because in some methods, IteratorNext and IteratorValue being abrupt doesn't close the iterator, but in other methods, it does. it seems like it should consistently be one or the other?
22:54
<bakkot>
ljharb: correct, iteratorstep and iteratorvalue throwing is considered misbehaving and so does not close the iterator
22:55
<bakkot>
if there are cases where those things throw and the iterator is still closed, that's a bug
22:55
<bakkot>
(but you might be looking at flatMap, which is a special case because there are two iterators)
22:55
<ljharb>
yes - in take/drop
22:55
<ljharb>
the two throwing AOs are done in a oneliner, so the abrupt check isn't separated
22:55
<ljharb>
i can make a PR
22:55
<bakkot>
which step in take/drop?
22:56
<ljharb>
eg 6.c.iii in drop
22:56
<bakkot>
look closer
22:56
<ljharb>
in that case maybe it's just that the check should be removed?
22:56
<ljharb>
ohhhh i see
22:56
<ljharb>
it's just the Yield completion
22:56
<bakkot>
indeed
22:57
<bakkot>
i.e., when someone calls .return() or .throw() on the iterator produced by .drop()
22:57
<ljharb>
what kind of code would make Yield throw?
22:57
<ljharb>
ahhh
22:57
<bakkot>
(via GeneratorResumeAbrupt IIRC)
22:57
<ljharb>
so if they've already called those, then yield would throw then?
22:57
<bakkot>
what do you mean by "already called"?
22:58
<ljharb>
maybe i'm not understanding. to get to 6.c.iii in drop, you've received an object from the next call. the IteratorValue call means that the Get of value has succeeded. when would return/throw factor in?
22:59
<ljharb>
is it that next or a value getter could have called .return or .throw, setting the GeneratorState to completed, thus causing Yield to throw?
22:59
<bakkot>
the call to the Yield AO pauses the "generator"
22:59
<bakkot>
and while it is paused, someone calling .throw() on the iterator causes return value returned by the Yield AO to be a throw completion
22:59
<bakkot>
this is the same as for an actual generator
22:59
<ljharb>
ahhh ok, that's the part i'm missing, thanks
23:00
<ljharb>
obv in my polyfill i'm doing some nasty stuff to simulate generators, so there's probably some of the basic mechanics that i still need to polish
23:00
<bakkot>
the value returned by the Yield AO is the thing passed by the consumer of the generator, as an argument to .next() or .return() or .throw()
23:01
<ljharb>
i think i get it. i am looking forward to these test cases being written :-) since i think that will clear it up for me much faster
23:05
<bakkot>

simple test for this example:

let manualIter = {
  next(){ console.log('next'); },
  throw(){ console.log('not hit'); },
  return() { console.log('closing'); },
};

let taken = Iterator.from(manualIter).take(10);
taken.next(); // prints 'next'
try { taken.throw('err'); } catch (e) { console.log('caught', e); } // prints 'closing' and then 'caught err'
23:31
<ljharb>
hm, neither IteratorPrototype nor WrapForValidIteratorPrototype have a Symbol.toStringTag, which makes debugging with them super annoying (ie, with the wrapper from Iterator.from). can one or both of these get a toStringTag?
23:36
<bakkot>
IteratorPrototype has a toStringTag: https://tc39.es/proposal-iterator-helpers/#sec-iteratorprototype-@@tostringtag