Sept 20 TC39 Meeting Notes

Brendan Eich brendan at
Fri Sep 28 00:22:42 PDT 2012

Rick Waldron wrote:
> Notably: Significant dissent on throwing exceptions for [iteration 
> protocol termination] control flow.

Counter-argument based on Python design and experience is that by far 
the most uses of iterators never have to try/catch and simply use for-of 
(for-in in Python) constructs: loops, comprehensions, generator 
expressions. The StopIteration exception cannot escape such constructs 
and won't be an issue in real debuggers (which must always provide 
exception filters, including sane defaults).

BE cites years of experience with thousands of users via Python 2.5+ and 

BE hierarchy of user population sizes related by >> ("much greater than"):

  | group 1: users of iterators via for-of, no try-catch needed, no 
problems |

 >>  | group 2: implementors of iterators who do not need to try-catch, 
just throw StopIteration |

 >>  | group 3: implementors of task.js-like raw try/catch-StopIteration 
coroutine libraries |

Some debate about ordering of group 2 vs. 3 sizes, LH cited C# different 
experience but BE pointed to different design evolution and final design 

> YK: (Question about use of in-band return?)

Disallows iterating over the in-band value. We've discussed this in the 
past, want true OOB StopIteration to avoid this ad-hoc and uncheckable 

> Discussion about protocol specifications, where precedent exists.

Rehashed Java (hasMore/getNext) and C# (Current/MoveNext) protocols 
involving two methods, which costs more for implementors (groups 2 and 
3, however ordered) and adds incoherence hazard (two methods get out of 
sync; C# tries to mitigate common mistake with Java's, but still has 
dual out-of-sync hazard to Java's).

MM agreed with BE that Python's is simplest given other constraints we 
can't change, or "least bad".

Consensus holds in my view and if it didn't we couldn't hold it on a 
great many things. I write these notes with some trepidation since 
iteration protocols and exceptions for restricted control effects are 
always going to excite debate. But full disclosure is best. These are my 
missing notes for the meeting notes, which I thought got too sparse here.


More information about the es-discuss mailing list