The nuance is that it is far more concise, making it more useful for frequent immutable updates, and it brings consistency with array spread (it was briefly considered to make a symbol for customizing object spread, but it was ultimately rejected for reasons I can't remember). Also, the optimizations would be much less speculative (you could perform them at the baseline level for object spread with some effort, unlike with `Object.assign`).
On Tue, Feb 13, 2018, 07:26 Bob Myers <[email protected]> wrote: > Cool. I don't claim to fully understand this, but as I read your issue, it > seems the optimization could/would apply to either spread properties OR > `Object.assign` case. If that's true, then there's nothing specially > optimizable about spread properties, in which case that particular point > would NOT have been a reason to support its adoption. Or is there some > nuance I'm missing? > > On Tue, Feb 13, 2018 at 4:58 PM, Isiah Meadows <[email protected]> > wrote: > >> BTW, regarding engine optimizability of those, I've filed a couple V8 >> bugs: >> >> - https://bugs.chromium.org/p/v8/issues/detail?id=7435 (object spread >> + `Object.assign`) >> - https://bugs.chromium.org/p/v8/issues/detail?id=7436 (array spread + >> `Array.prototype.concat`) >> >> There are things engines *could* do that they *aren't currently >> doing*. Part of why I proposed V8 take a look at this is because it >> has one of the more flexible IC systems out of all the engines (they >> can lower `Array.prototype.map` to a simple loop for dense arrays even >> though a simple `delete array[index]` within the loop breaks the >> assumption - this is *exceptionally* difficult to implement with the >> ability to deoptimize). >> ----- >> >>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
