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 <isiahmead...@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).
> -----
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to