Destructuring and evaluation order

[Oliver Hunt]

On Apr 25, 2014, at 10:42 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

> 
> On Apr 25, 2014, at 10:25 AM, Oliver Hunt wrote:
> 
>> 
>> On Apr 25, 2014, at 4:24 AM, Andreas Rossberg <rossberg at google.com> wrote:
>> 
>>> The way destructuring assignment currently is specified leads to
>>> rather inconsistent evaluation order. Consider:
>>> 
>>> let o = {}
>>> function f() { print(1); return o }
>>> function g() { print(2); return 5 }
>>> 
>>> f().x = g()    // 1, 2
>>> {a: f().x} = {a: g(}}   // 2, 1
>>> 
>>> That is, destructuring assignments violate the left-to-right
>>> evaluation that is otherwise maintained.
>>> 
>> 
>> I don’t believe that there is any reason to break from left-to-right evaluation order.  Even if it was uncommon it’s still an unnecessary hazard.
>> 
>> Spec bug maybe?
> 
> Nope, it's always been designed this, going back to the original wiki strawman http://wiki.ecmascript.org/doku.php?id=harmony:destructuring#semantics and I assume the original FF implementation.
> 
> It has also been something that we has been discussed here and in TC39 multiple times.  If we wan to revisit this decision we really need to dredge up all of those previous discussions to see if there is new data that would cause us to change this decision. 
> 
> Basically for destructing assignment, each property element can be an arbitrary assignment expression and all of their Reference values would have to be saved to get left to right order. 

Yup.  Honestly I don’t think destructuring to an arbitrary expression would be that common so I think it’s worth it to define order of operations as being left to right and leave it to the engines to optimise things sanely.

Burning some stack space to hold the intermediate slots doesn’t seem that bad, although that said I’ve forgotten what the semantics for

o = {__proto__: {set foo() {print(“bar”)}}
o.foo = (o.__defineSetter__(“foo”, function(){ print(“foo”)})), 5

Is expected to be (I could see what we actually _do_ but that’s no guarantee that it’s the right thing).

—Oliver


> 
> Allen
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140425/1c9f97fb/attachment.html>