Suggestion: Destructuring object initializer.

[Isiah Meadows]

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 gol.com> 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 gmail.com>
> 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).
>> -----
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180213/fec01fa5/attachment.html>