There currently are *not*, and I can tell you that the suggested optimization for `Object.assign` would be substantially more complex. It's possible they may turn down the `Object.assign` optimization until later, also - they *don't* perform optimizations based on the way a function is called beyond argument count/type currently, which also prevents them from eliding the return value allocation in the common case of `splice`-to-remove-from-arrays.
----- Isiah Meadows [email protected] Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com On Tue, Feb 13, 2018 at 10:12 PM, Bob Myers <[email protected]> wrote: > Thanks for engaging. > > This entire little sub-thread, and my question about what nuance I was > missing, was related to one single item on your useful list of reasons why > property spread was a good idea, namely your assertion that property spread > permits engine optimizations which are different, or better, or easier, than > those possible with `Object.assign`. > > I asked about this specifically because I had been under the impression that > `{...a, ...b}` is semantically equivalent *in every regard* to > `Object.assign(a, b)`. Then I was hoping that the issue you posted to the V8 > issue tracker would cast light on the difference, but could not see anything > there that helped me understand it either. On the contrary, in your post as > I read it you seem to be assuming/implying that the two cases are equivalent > in terms of opportunities for optimization. > > I am perfectly willing to consider reasons for bringing in property spreads > such as "parity" or "brevity". It's a separate discussion as to whether or > not those other criteria do or do not apply, or to what degree they might > apply, to property picking. First, I just want to understand the point about > engine optimization, because if that is actually the case it would seem to > be a very compelling argument. The simple version of the question is, are > there or are there not engine optimizations specifically made possibly by > property spread syntax which would not be possible with `Object.assign`, and > if so what are they? > > Bob > > > On Wed, Feb 14, 2018 at 12:44 AM, Isiah Meadows <[email protected]> > wrote: >> >> 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
