ES6: var a,b,c; [a,b,c]=[1,2,3]; - destructuring assignments - Is that something coming soon?

I know that there is always hunger for every thing to be in Espruino... ;-)

This multi-assignment / array and object destructuring assignment could give some space relieve for quite many things (the example though does not really portray that):

>var a,b,c;
=undefined
>[a,b,c]=[1,2,3]
Uncaught Error: Unable to assign value to non-reference Array
 at line 1 col 15
[a,b,c]=[1,2,3]
              ^
>

Would work for returns from functions as well:

>var a,b,c;
=undefined
>var trippler = function(){ return [1,2,3]; }
=function () { ... }
>[a,b,c] = trippler();
Uncaught Error: Unable to assign value to non-reference Array
 at line 1 col 20
[a,b,c] = trippler();
                   ^
>

I 'expect' only the simple implementation(s)... even though sometimes nothing is better than not all...

There's no plan for it right now, but it's definitely worth voting for on the ES6 wishlist.

The issue is that as you mention "sometimes nothing is better than not all..." - while I'm sure most people would prefer to be able to use it in a simple way, if other features are anything to go by it's pretty much guaranteed I'll get "obscure feature X isn't working" bugs filed based on it, so if I implement it I'd have to be pretty clear about what was implemented.

Also - to be sure I don't get your hopes up - this is another ES6 feature that's really unfriendly to implement in Espruino's parser, because you don't actually know whether [a,b,c] is an array or a destructuring assignment until you get to the = sign.

this is another ES6 feature that's really unfriendly to implement in Espruino's parser, because you don't actually know whether [a,b,c] is an array or a destructuring assignment until you get to the = sign.

I can vividly see that... because you try to resolve every '(sub)expression' as soon as possible. For the simplest solution - (plain) variable references - It would require to keep a prallel array with the references and when the = shows throw either away and continue processing accordingly. An optimization could be by having a first level of array construction with simple value object references only - no functions and other ('complex') objects - and have an earlier decision of continuing with array build process... what would then either throw an error when hitting the = sign or keep going and 'emptying' the result stack onto the references kept in the array. (...as seen from my interpreter-illiterate 'frog perspective'.) I guess the detection of wether the array element - in the anonymous array (and that is the only array type it would work) - is a plain var reference or something else is the challenge... --- Resolution of the encountered array element(s) is postponed until a non-simple-value-object-reference (variable) his hit or the array closes.

PS: Did 'vote' on the ES6 wishlist. It is all very relative due to the nature of Espruino.

Yes - I actually do something similar for arrow functions (eg. (a,b,c) vs (a,b,c)=>a+b+c)

However that's not too bad because doing (a,b,c) in normal code is very rare so it doesn't hurt to take a small performance hit when parsing. [a,b,c] in normal JS is super common though so the last thing we want to do is make that noticeably slower :)

It's a new javascript construct in ES 6 that allows you to match property of an object in assignment. The syntax you need is:

const { local: loc } = this.props

which translates to: "declare a constant loc and assign it the value of property local from this.props".

Mon 2021.009.20

'It's a new javascript construct in ES 6'

New is a bit misleading. . . . New back in 2015

https://exploringjs.com/es6/ch_about-es6.html

While that (post #5) is a simple example @user134371, it is only a subset. A better reference:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment

A plethora of examples:

https://hacks.mozilla.org/2015/05/es6-in-depth-destructuring/
https://exploringjs.com/es6/ch_destructuring.html

BTW @allObjects and @Gordon were discussing the intricacies and performance issues under the assumption there might be an inclusion in the future. I'm quite certain they've explored those complexities after pouring over the ECMAScript specification.