On Apr 7, 2014, at 12:06 PM, Marcus Stade wrote:

> Thanks Allen! When reading the issue, I can't quite make out what the reasoning is for setting this constraint on the iterator protocol. Locking down the behavior of Map/Set/Array iterators is fine I suppose (although I'd argue against the permanently closed behavior) but I reckon it seems a bit overkill to specify that custom iterators must have the same behavior. It seems arbitrary, but perhaps more importantly I'm not sure how engines should enforce this behavior or why this added complexity is necessary. If engines don't enforce it, then this language doesn't really matter much for the general iterator protocol anyway. I'm also very open to the possibility that I've misunderstood the whole thing.
> 
No enforcement is required by the specification.  If you create an iterator that doesn't fully conform to the iterator interface specification and then get  surprising results, its your fault, not the implementation's.

Allen




> Much obliged to for your feedback!
> 
> -- Marcus
> 
> 
> On Mon, Apr 7, 2014 at 5:47 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> see https://bugs.ecmascript.org/show_bug.cgi?id=2003 which was the original issue that motivated the currently spec'ed  behavior. 
> 
> 
> 
> 
> 
> 
> On Apr 7, 2014, at 3:30 AM, Marcus Stade wrote:
> 
>> Thanks for filing that! Now I also know where to file bugs, so doubly thanks!
>> 
>> -- Marcus
>> 
>> 
>> On Mon, Apr 7, 2014 at 10:00 AM, David Bruant <bruant.d at gmail.com> wrote:
>> Le 07/04/2014 02:31, Marcus Stade a écrit :
>>> In section 25.1.2 of the spec it says:
>>> 
>>> The function returns an object that conforms to the IteratorResult interface. If a previous call to the next method of an Iterator has returned an IteratorResult object whose done property is true, then all subsequent calls to the next method of that object must also return an IteratorResult object whose done property is true,
>>> 
>>> Are there any practical reasons why the Iterator interface explicitly disallows this?
>> There is no good reason indeed. Worse, there is no way to enforce it on user-generated iterators, so it'd be dangerous for standard iterator consumers to assume such a property.
>> 
>> This mention should probably be removed altogether.
>> Filed https://bugs.ecmascript.org/show_bug.cgi?id=2606
>> 
>> Thanks,
>> 
>> David
>> 
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140407/be24390b/attachment.html>

No enforcement is required by the specification.  If you create an iterator that doesn't fully conform to the iterator interface specification and then get  surprising results, its your fault, not the implementation's.