| 06:30 | <ljharb> | they're different for a reason tho :-) there's a whole closed issue on ecma262 with tons of discussion about it |
| 07:55 | <Ashley Claymore> | This does not surprise me š |
| 19:21 | <Timo Tijhof> | Ashley Claymore: https://stackoverflow.com/q/47155141/319266 - https://github.com/tc39/ecma262/issues/687. TLDR: Object spread is equivalent to Object.assign which tolerates undefined. Array spread actually related to iterables, not arrays specifically, and so requires an iterator (value -> Symbol.iterator -> next -> etc), so there's more potential for unintended errors there (undefined? null? object without iterator? object with null/undefined iterator? iterator with null/undefined next function, etc). In practice, though, the reason is simply that it is how it is because it is that way ā for web compat. Although having an API accept more than before and throw fewer errors would not be the most unthinkable change. Maybe, if someone puts in the time :) |
| 19:32 | <bakkot> | The time to do the change is trivial; the thing in the way of making the change is that a number of people think it should not be made |
| 19:32 | <bakkot> | (and it would indeed almost certainly be web-compat) |
| 19:34 | <bakkot> | Personally I am much more interested in changes along the lines of making Array.prototype[Symbol.iterator] unforgeable so that engines could trivially elide the allocation in ...(foo ?? []) |
| 19:34 | <bakkot> | some people do not like unforgeable builtins for reasons of polyfills or whatever but I think this one would be worth it |
| 19:34 | <bakkot> | someday, maybe |
| 19:47 | <ljharb> | what do you mean unforgeable? or do you just mean, nonconfigurable |
| 19:47 | <ljharb> | it wouldn't be a problem for polyfills to make it nonconfigurable as long as we never, ever change the function in the future, fwiw |
| 20:19 | <kriskowal> | I think āincorruptibleā might be the right word for what folks writing polyfills and platforms are looking for, in the sense that subsequently run code ideally canāt interfere with their integrity. |
| 20:52 | <ljharb> | well, tbf, in general nonconfigurable things suck for polyfills, because if they're implemented wrong, a polyfill can't fix it |
| 22:38 | <bakkot> | sorry, yeah, by "unforgeable" I mean nonconfigurable & nonwritable |
| 22:38 | <bakkot> | so yes it would mean polyfills couldn't fix it |
| 22:38 | <bakkot> | but I think that in this specific case it would be worth it anyway |