<div dir="ltr">Thanks for engaging.<div><br></div><div>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`. </div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Bob</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 14, 2018 at 12:44 AM, Isiah Meadows <span dir="ltr"><<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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`).</p><div class="HOEnZb"><div class="h5">
<br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 13, 2018, 07:26 Bob Myers <<a href="mailto:rtm@gol.com" target="_blank">rtm@gol.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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?</div><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 13, 2018 at 4:58 PM, Isiah Meadows <span dir="ltr"><<a href="mailto:isiahmeadows@gmail.com" target="_blank">isiahmeadows@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">BTW, regarding engine optimizability of those, I've filed a couple V8 bugs:<br>
<br>
- <a href="https://bugs.chromium.org/p/v8/issues/detail?id=7435" rel="noreferrer" target="_blank">https://bugs.chromium.org/p/<wbr>v8/issues/detail?id=7435</a> (object spread<br>
+ `Object.assign`)<br>
- <a href="https://bugs.chromium.org/p/v8/issues/detail?id=7436" rel="noreferrer" target="_blank">https://bugs.chromium.org/p/<wbr>v8/issues/detail?id=7436</a> (array spread +<br>
`Array.prototype.concat`)<br>
<br>
There are things engines *could* do that they *aren't currently<br>
doing*. Part of why I proposed V8 take a look at this is because it<br>
has one of the more flexible IC systems out of all the engines (they<br>
can lower `Array.prototype.map` to a simple loop for dense arrays even<br>
though a simple `delete array[index]` within the loop breaks the<br>
assumption - this is *exceptionally* difficult to implement with the<br>
ability to deoptimize).<br>
-----<br>
<br></blockquote></div></div></div></blockquote></div>
</div></div></blockquote></div><br></div>