Spread and non objects
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
> 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 (184.108.40.206 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 (220.127.116.11 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...
More information about the es-discuss