Spread and non objects

Dean Landolt dean at deanlandolt.com
Fri Nov 5 08:32:31 PDT 2010


On Fri, Nov 5, 2010 at 11:23 AM, Brendan Eich <brendan at mozilla.com> wrote:

> On Nov 5, 2010, at 7:56 AM, Jon Zeppieri wrote:
>
> > Second issue: Erik suggests (plan B) that null and undefined are
> specifically special cased. I can't tell whether Brendan agrees with that or
> wants spread to be legal on any input whatsoever, because he writes that
> spread "should return an empty array on mismatch."
>
> No, that was about feedback over the years on regexp.exec's return value!
>
> Back to spread: the general case of ... is to spread an array-like (ES5
> hasn't quite defined this, but it is getting there) into positional
> parameters or positional array initialiser elements. Any non-array-like
> could be an error (plan A), but for the reason John Lenz cited, ...undefined
> as a special non-throwing case that is equvalent to [] seems better (plan
> B).
>
> I dislike the null == undefined taint, useful though it is in real-world JS
> that does not abstain from == altogether. So I wonder whether ...null should
> not throw.
>
> Function.prototype.apply is, as Erik's o.p. pointed out, the
> counter-argument, since (15.3.4.3 step 2 in ES5) it turns null or undefined
> into [].
>
> What about other primitives? ...42, ...true, and ..."foo" could throw, as
> Function.prototype.apply would do (15.3.4.3 step 3).
>
> I think matching Function.prototype.apply is best, having reviewed all
> this. Comments?
>


Considering the primary use-case for spread is a sugaring for
Function.prototype.apply I would expect the same semantics.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101105/dbe1027a/attachment.html>


More information about the es-discuss mailing list