Joe, I don't think we're having the same discussion.
Again, this is about the issue Katelyn raised about the return value of
`.next`.
Katelyn suggested that the return value of a `.next` call in the iteration
protocol - an object of the form `{value: value, done: boolean}` should be
allowed to be reused between calls - so an iterator can return _the same_
object without allocating a new one.
I argue (and from what I understand Kevin agrees with me) that allowing
this is error prone and might cause surprises for developers since they
have an object returned that has mutated implicitly without the consumer
being aware. We can have the same performance gain by a clever engine that
figures this sort of thing out itself.
On Sun, Feb 15, 2015 at 4:13 PM, joe <joe...@gmail.com> wrote:
> Again, where does this mutation occur? The spec shouldn't allow any such
> thing to begin with; it should mandate exactly what my compiler does: as
> soon as .next returns, copy .value into the loop variable. The developer
> shouldn't have any access to the return value from within the loop at all;
> if he does, that should (ideally) be considered a violation of the standard.
>
> On Sun, Feb 15, 2015 at 8:09 AM, Kevin Smith <zenpars...@gmail.com> wrote:
>
>> When I can get more sound abstractions for no additional cost
>>> (eventually) I'd rather not introduce implicit mutable state into the
>>> application. Developers won't be aware of it being mutating and the whole
>>> notion of a mutating-at-a-later-point return value is very error-prone in
>>> my opinion.
>>>
>>
>> Right. Mutating the returned object isn't really tenable from a usability
>> point of view.
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
