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.

[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.

[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?

[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.

[trusktr]

I was scratching my head trying to find a bug in an application, when I realized that it was due to something like

var obj = { ...otherObj.someUndefinedValue }

I strongly believe that errors would be super helpful here.

As with arrays, it would also easy to write

var obj = { ...(otherObj.someUndefinedValue || {}) }

to explicitly opt out of error behavior.

But it would be too late to change the spec, right?

[ljharb]

Yes, it would break a ton of code if that started throwing.

[mathiasbynens]

#1069

[Lukom]

You have to write [...[].concat(maybeArr || [])] instead of [...maybeArr] to handle singular/null/undefined values. Haha javascript, what a joke.

[bathos]

[ ...maybeArr || [] ] is sufficient there @Lukom

Edit: nm, didn’t catch the ‘singular’

[ericketts]

@Lukom no reason to then spread that into another array, keep it

const x = [].concat(maybeArrOrObject || []);

hell you can throw as many args into concat as you want so even if you need additional items added there's no reason for the outer spread.

on the topic at hand, I agree with the poster up a ways, that it is surprising to me that this sort of confusing "gotcha" made it into the language during a time when there's been such an effort to make JS less confusing for newcomers and novices. I certainly can appreciate why it ended up this way, but for syntax that is aesthetically identical, it is a bit surprising that it behaves differently for the 2 "main" collection types used in the lang (there are many more now but you know what I mean). (also strange I'd never considered specifically this, until just now).

[alexfromapex]

People are being mislead by [].concat(whatever || []) because that's going to drop falsy values like 0 instead of just null and undefined.

[devsnek]

You can use [].concat(whatever ?? []) now :P

[geryogam]

The number of likes in this thread shows that there is clearly a language issue. undefined and null represent emptiness without a specific type, they don't represent only empty objects, so they should be usable in any contexts where an empty value is accepted: both object spread and array spread. I don't think anybody relies on this design issue (thrown error when undefined or null is spread in an array) so it seems safe to fix. Can we reopen this issue?

[ljharb]

Lots of code relies on it, it’s not safe to fix, and i doubt anyone would have the appetite to risk it.