Array spread throws on undefined/null but object spread doesn't

[olalonde]

(Pardon if this isn't the right place to discuss this)

I've noticed an annoying inconsistency between how object and array spread behave, namely that object spread silently ignores null/undefined while array spread throws an error:

$ babel-node
> var fn1 = (obj) => { return { ...obj } }
'use strict'
> fn1()
{}
> var fn2 = (arr) => { return [ ...arr ] }
'use strict'
> fn2()
TypeError: Cannot read property 'Symbol(Symbol.iterator)' of undefined
    at fn2 (repl:4:14)
    at repl:3:1
    at ContextifyScript.Script.runInThisContext (vm.js:25:33)
    at Object.exports.runInThisContext (vm.js:77:17)
    at _eval (/Users/olalonde/.nvm/versions/node/v6.5.0/lib/node_modules/babel-cli/lib/_babel-node.js:95:23)
    at REPLServer.replEval (/Users/olalonde/.nvm/versions/node/v6.5.0/lib/node_modules/babel-cli/lib/_babel-node.js:177:14)
    at bound (domain.js:280:14)
    at REPLServer.runBound [as eval] (domain.js:293:12)
    at REPLServer.<anonymous> (repl.js:504:10)
    at emitOne (events.js:96:13)

I was wondering what was the rationale for array spread throwing an error on undefined/null and if perhaps object spread could adopt the same behaviour or vice versa.

[ljharb]

The right place would be the repo for the object spread proposal - the rationale is because it 1:1 maps to Object.assign.

[ljharb]

The right place would be the repo for the object spread proposal - the rationale is because it 1:1 maps to Object.assign.

[olalonde]

Yeah, I prefer that behaviour actually. I was more hoping that array spread could adopt the same behaviour but I suppose that ship has sailed?

[olalonde]

Yeah, I prefer that behaviour actually. I was more hoping that array spread could adopt the same behaviour but I suppose that ship has sailed?

[ljharb]

Array spread isn't "array spread", it's "iterable spread", so different rules apply.

[ljharb]

Array spread isn't "array spread", it's "iterable spread", so different rules apply.

[olalonde]

Would a proposal to modify "iterable spread" to ignore undefined/null be considered?

[olalonde]

Would a proposal to modify "iterable spread" to ignore undefined/null be considered?

[ljharb]

That would be a breaking change for anybody who was relying on the throw behavior. What would be the benefit of that, when you can do ...(maybeArr || []) if that's the behavior you want?

[ljharb]

That would be a breaking change for anybody who was relying on the throw behavior. What would be the benefit of that, when you can do ...(maybeArr || []) if that's the behavior you want?

[olalonde]

Yes, it would indeed be breaking which is why I supposed the ship had sailed. Does Ecmascript ever break forward compatibility? ...(maybeArr || []) is what I've been doing in my own code, or with default params when possible (arr = []) => ([...arr]). I do think it would've been more elegant for [...arr] and {...obj} to treat undefined/null similarly. Going to close this because I don't think there'd be a way to change that behaviour without breaking forward compatibility.

[olalonde]

Yes, it would indeed be breaking which is why I supposed the ship had sailed. Does Ecmascript ever break forward compatibility? ...(maybeArr || []) is what I've been doing in my own code, or with default params when possible (arr = []) => ([...arr]). I do think it would've been more elegant for [...arr] and {...obj} to treat undefined/null similarly. Going to close this because I don't think there'd be a way to change that behaviour without breaking forward compatibility.

[mcmar]

This little "gotcha" just caught me by surprise too. I can understand the history of how this happened, but it does look like a mistake in language design from my perspective. Maintaining equivalency between the two spread operator syntaxes helps developers. Javascript already has too many gotchas. I'd hope we could avoid introducing more.
And while I understand the need to maintain compatibility, I also doubt that there are many people who are relying on the spread operator throwing an error for their code to function correctly.

[mcmar]

This little "gotcha" just caught me by surprise too. I can understand the history of how this happened, but it does look like a mistake in language design from my perspective. Maintaining equivalency between the two spread operator syntaxes helps developers. Javascript already has too many gotchas. I'd hope we could avoid introducing more.
And while I understand the need to maintain compatibility, I also doubt that there are many people who are relying on the spread operator throwing an error for their code to function correctly.