Suggestion: Destructuring object initializer.
isiahmeadows at gmail.com
Tue Feb 13 19:14:00 UTC 2018
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
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>
>> BTW, regarding engine optimizability of those, I've filed a couple V8
>> - 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 +
>> 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...
More information about the es-discuss