Suggestion: Destructuring object initializer.

Bob Myers rtm at
Wed Feb 14 03:12:56 UTC 2018

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?


On Wed, Feb 14, 2018 at 12:44 AM, Isiah Meadows <isiahmeadows at>

> 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 <rtm at> 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 <isiahmeadows at>
>> wrote:
>>> BTW, regarding engine optimizability of those, I've filed a couple V8
>>> bugs:
>>> - (object spread
>>> + `Object.assign`)
>>> - (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 `` 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).
>>> -----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list