Suggestion: Destructuring object initializer.

[Richard Gibson]

I'm unsure if `Object.assign(a, b)` and `{...a, ...b}` are equivalent in
terms of optimization opportunities, but I am certain that they are not
equivalent *in *every* regard* because Object.assign invokes setters but
object spread does not.

cf. https://github.com/tc39/ecma262/pull/1069#issuecomment-361007960 :

// throwslet a = Object.assign({ set x(v) { throw v } }, {x: 0});
// copies propertieslet b = { set x(v) { throw v }, ...{x: 0} };



On Tue, Feb 13, 2018 at 10:12 PM, Bob Myers <rtm at gol.com> wrote:

> 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?
>
> Bob
>
>
> On Wed, Feb 14, 2018 at 12:44 AM, Isiah Meadows <isiahmeadows at gmail.com>
> wrote:
>
>> 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).
>>>> -----
>>>>
>>>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180213/c60b9c4d/attachment.html>