ES6 draft, Rev20 is now available

Anne van Kesteren annevk at
Wed Oct 30 12:29:52 PDT 2013

On Wed, Oct 30, 2013 at 7:23 PM, Allen Wirfs-Brock
<allen at> wrote:
> Doesn't really depend upon the usage.  If an API is going to return a sequence<T> to JS code, it really should have an @@iterator.  But that is presumably a non-breaking change, from the JS perspective.  If an API wants to accept a sequence<T> it only needs it to have an @@iterator if it is actually going to use JS iterator semantics to process.  There is no reason that an implementation of such a consuming API couldn't do its own fall back to non-iterator based iteration.  That would be a non-breaking solution.

This is about the accepting side, not returning. The idea was for that
was to be the same as the spread operator. Of course we could do
something else and have it compatible with current IDL semantics, but
that's not very coherent, nor desirable long term. So either the
spread operator changes or we change sequence<T>. Going forward it'd
be great if we tried to reason about these things platform-wide,
rather than JavaScript-wide.


More information about the es-discuss mailing list