Suggestion: Destructuring object initializer.

[Bob Myers]

Thanks for pointing that out, but remember that the `Object.assign`
equivalent of `{...a, ...b}` is

```
Object.assign({}, a, b)
```

In other words, you are always starting off with an empty object, with no
setters lying in wait to throw or do anything else. So the question is, are
there any differences in terms of engine optimizability between the above
and `{...a, ...b}`?

and
Bob

On Wed, Feb 14, 2018 at 10:23 AM, Richard Gibson <richard.gibson at gmail.com>
wrote:

> 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/20180214/8f19f2d3/attachment-0001.html>