StopIteration, ForwardToTarget, ... & symbols

David Bruant bruant.d at
Tue Nov 27 00:59:26 PST 2012

Le 27/11/2012 02:27, Brendan Eich a écrit :
> David Bruant wrote:
>> Le 26/11/2012 22:11, Brendan Eich a écrit :
>>> Herby Vojčík wrote:
>>>> Hi,
>>>> shouldn't StopIteration, ForwardToTarget from "Notification 
>>>> proxies" thread and similar ones be rather well-known unique 
>>>> symbols (like @iterator), now that we have them, instead of 
>>>> well-known globals? \
>>> Why?
>>> Let's separate the naming and unique identity concerns. Objects have 
>>> unique identity, so do symbols. But if a unique identity is required 
>>> without being a property key, then an object is the right answer, 
>>> not a symbol.
>> I'm not sure not being a property key is that big of a constraint, so 
>> I would say that objects and symbols are both valid equally valid.
> Perhaps not, but it's odd to make a symbol just for (e.g.) 
> immutability with no properties or [[Prototype]]. For 
> realm-independence is more interesting.
I'm not sure I understand your reluctance to symbols.
In practice, I would use "throw StopIteration" (or ForwardToTarget if 
such a thing comes to existence) and I couldn't care less if the value 
has a [[Prototype]] or not, is mutable or not, or can be used as 
property key or not. As a matter of fact, only the identity (or 
[[NativeBrand]]) of this value is used by the engine, so none of the 
rest matters in one direction or the other.

I have been thinking more about it, because "throw StopIteration" feels 
a bit like a hack in the sense that the goal is not to throw an error. 
Actually, it's already known in the iterator protocol that the error 
will be caught by the direct caller (the JS engine).
What we need is a way to end a frame in a way that unambiguously 
signifies that the iteration stops. The Legitimate Way™ would be to add 
a new "stopiteration [reason];" statement to end a frame. But it doesn't 
scale that well (and probably isn't backward compatible). So hacking 
into the two ways to end a frame we currently have (return and throw) is 
what we use.
Throwing a unique value (or a "class" of values) can be seen as an 
extensibility mechanism aimed at enabling user-defined frame-ending 
Now, with things seen from this angle, an object or a symbol doesn't 
make much of a difference and is more of an implementation detail than 
anything else.


More information about the es-discuss mailing list