That's odd/interesting, but for the purposes of my bug, that is
covered as part of the "no previous fields have been assigned to the
literal", and thus would prevent the optimization statically in either
case. However, arrays could afford looser restrictions (since 1.
properties aren't preserved, and 2. you can always just bulk-move
properties using intrinsics).
-----
Isiah Meadows
m...@isiahmeadows.com
Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com
On Tue, Feb 13, 2018 at 11:53 PM, Richard Gibson
<richard.gib...@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 :
>
> // throws
> let a = Object.assign({ set x(v) { throw v } }, {x: 0});
>
> // copies properties
> let b = { set x(v) { throw v }, ...{x: 0} };
>
>
>
> On Tue, Feb 13, 2018 at 10:12 PM, Bob Myers <r...@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 <isiahmead...@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 <r...@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 <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
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
