On Apr 25, 2014, at 10:42 AM, Allen Wirfs-Brock <al...@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 <rossb...@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 > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss