I don't think I'm making my case very clear, my apologies. Hopefully, I'll
be able to clarify in this message.

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.


This is the very point I'm trying to make: the spec uses language such as
"must" when declaring how iterators should behave, yet an implementation
isn't as you say required to enforce such behavior. In this case, I am
getting "surprising results" because the spec seems to say that the way
I've implemented the iterators above is flat out wrong; yet, the code runs
just fine and sugar such as `for..of` is working just as it would with a
fully conforming iterator. If it quacks like a duck..

I might be reaching, but I do think the language is confusing. If the
intent is to convey a practice or precedence set by the built in iterators,
then perhaps it's better to make this explicit or use words such as
"recommended" instead of "must". Perhaps I'm bike shedding, in which case I
apologize. I hope I've made my point clearer any way.

Ps. I like what Scott's saying, which I *think* is pretty much what I'm
trying to say as well, albeit I'm doing a poorer job at it.

-- Marcus


On Mon, Apr 7, 2014 at 10:42 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> 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<http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_drafts&cache=cache&media=harmony:working_draft_ecma-262_edition_6_04-05-14.pdf>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/20140409/bff65f8c/attachment.html>

I don't think I'm making my case very clear, my apologies. Hopefully, I'll
be able to clarify in this message.

> 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.


This is the very point I'm trying to make: the spec uses language such as
"must" when declaring how iterators should behave, yet an implementation
isn't as you say required to enforce such behavior. In this case, I am
getting "surprising results" because the spec seems to say that the way
I've implemented the iterators above is flat out wrong; yet, the code runs
just fine and sugar such as `for..of` is working just as it would with a
fully conforming iterator. If it quacks like a duck..

I might be reaching, but I do think the language is confusing. If the
intent is to convey a practice or precedence set by the built in iterators,
then perhaps it's better to make this explicit or use words such as
"recommended" instead of "must". Perhaps I'm bike shedding, in which case I
apologize. I hope I've made my point clearer any way.

Ps. I like what Scott's saying, which I *think* is pretty much what I'm
trying to say as well, albeit I'm doing a poorer job at it.