Suggestions for Set

Rick Waldron waldron.rick at
Wed Oct 3 12:50:17 PDT 2012

On Wed, Oct 3, 2012 at 2:57 PM, Brendan Eich <brendan at> wrote:

> Jason Orendorff wrote:
>> On Wed, Oct 3, 2012 at 11:34 AM, Brendan Eich<brendan at>
>>  wrote:
>>> * the spread syntax just uses the iteration protocol;
>>> This differs from Array.from -- any reason not to fall back on the
>>> array-like protocol (which for missing 'length' iterates no values)?
>> I think ES6 should have a single how-to-iterate behavior shared by
>> Array.from, spread syntax, and for-of.
>> Whether that includes a fallback to .length or not seems less important
>> to me.
>> It seems simpler *not* to include the fallback. Firefox doesn't
>> include it at present. Instead, arraylike objects are pretty much all
>> iterable. That wasn't hard to do, since our Array.prototype.iterator
>> is generic.
> I buy it.
> Not sure why we didn't do it in the July meeting where we settled on
> Array.from testing iterable and falling back on array-like. Perhaps fear
> that @iterator customizations will be missing from a number of array-likes.

I didn't realize that existing built-ins and DOM APIs would be modified to
implement the iterator protocol.

One of the reasons we decided to make spread, rest and destructuring
"array-like" only was to limit the surprise factor that would occur with
sparse arrays. The behaviour we wanted to avoid is present in Firefox 18

var a = new Array(10);

// A
console.log( { return 1; }) ); // [, , , , , , , , , ,]
// B
console.log( [...a].map(function() { return 1; }) ); // [1, 1, 1, 1, 1, 1,
1, 1, 1, 1]

>From the notes:

Destructing and spread - no iterator protocol.
(return to existing draft semantics of arraylike — [Cannot be both iterable
and array-like])

I believe this was referring to iterator protocol filling in the holes
with undefined, creating an unexpected result, therefore something
cannot be both iterable and array-like without surprises. The result
of calling Array.isArray(a) and Array.isArray([...a]) will be be true,
but one appears to be constructed differently then the other.

Changing A to work like B could very well break things; but like Erik,
Andreas and I have said above, holes are a myth in real-world code.

At one point I believed I had a valid use case, but it turned out that
it was better to manually fill in with undefined.


> On that point, does NodeList have an iterator in Firefox now? That's an
> obvious Array.from argument

> type.
> /be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list