Re: [EXTERNAL] Re: Destructuring by

refs proposal I currently use `ref` rather than `&`, > since `&` is often ascribed to unmanaged memory addresses in many > languages, while `ref` (at least in C#) is specifically tied to references > to memory managed by the GC. That proposal explainer currently includes > examples for

RE: [EXTERNAL] Re: Destructuring by

n many languages, while `ref` (at least in C#) is specifically tied to references to memory managed by the GC. That proposal explainer currently includes examples for `ref` variables, parameters, expressions, destructuring, and support for reified `Reference` objects. In userland I currently have

Re: Destructuring by

c.) > - syntax sugars with strong community feedback AND battle proven prior art > (classes, destructuring, string templates, rest, spread and default > values, async/await, etc.) > - introducing or specifying new mechanisms that didn't exist before in > ecma (modules, classes, varargs, e

Re: Destructuring by

e to pass instances > >> and whole objects references around. > >> > >> You have a reference to a property, you don't see its source. > >> > >> > >> On Wed, Mar 3, 2021 at 6:19 PM Augusto Moura > >> wrote: > >>> > >>

Re: Destructuring by

t;> >> On Wed, Mar 3, 2021 at 6:19 PM Augusto Moura >> wrote: >>> >>> > ```js >>> > function stuff(source, extra) { >>> > const {value, method} = source; >>> > >>> > if (condition) >>> > method.call(source

Re: Destructuring by

ype, let/const and block scoping, nullish coalescing operator, etc.) - syntax sugars with strong community feedback AND battle proven prior art (classes, destructuring, string templates, rest, spread and default values, async/await, etc.) - introducing or specifying new mechanisms that didn't ex

Re: Destructuring by

t; >> > ```js >> > function stuff(source, extra) { >> > const {value, method} = source; >> > >> > if (condition) >> > method.call(source); >> > >> > if (value === extra) >> > source.value = 'no more'; >&g

Re: Destructuring by

021 at 6:19 PM Augusto Moura wrote: > > ```js > > function stuff(source, extra) { > > const {value, method} = source; > > > > if (condition) > > method.call(source); > > > > if (value === extra) > > source.value = 'no more'; > >

Re: Destructuring by

> ```js > function stuff(source, extra) { > const {value, method} = source; > > if (condition) > method.call(source); > > if (value === extra) > source.value = 'no more'; > } > ``` I mean, in this case you can skip destructuring altogether, havin

Re: Destructuring by

and easier to reason about, in IDEs (special highlights for referenced variables), in developers intent (no need to grab the source repeatedly when updates are needed), and in clarity (having an explicit & in destructuring describes the intent of wanting to deal with that value as reference). My onl

Re: Destructuring by

I don't know, the by reference destructuring seems a bit too much magical, a scoped variable that sets to a property to a object just sounds like the old `with` statement but reduced and more explicit, given is just a sugar and currently the problem is not a great of a pain point I would be very

Re: Destructuring by

Giammarchi < andrea.giammar...@gmail.com> wrote: > Another one (cit. DJ Khaled) > > has "by reference" ever been considered as "yet another JS syntax" ??? > > let object = {value: 1}; > let {} = object; > value = 2; > > object.value; // 2 >

Destructuring by

Another one (cit. DJ Khaled) has "by reference" ever been considered as "yet another JS syntax" ??? let object = {value: 1}; let {} = object; value = 2; object.value; // 2 allowed everywhere destructuring is possible, throwing for frozen properties ... is this just meh

Destructuring equivalent to nullish coalescing and optional chaining operators?

Hello! Has any equivalent feature for the nullish coalescing ?? and optional chaining ?. operators been proposed to paper over the deficiencies of the destructuring syntax with regards to null values? If not, I think one should be proposed. For the entire right side of the binding, an equivalent

Bind operator ... for destructuring

Hello there  this is going to be quick: how about using the bind operator *at least* for destructuring? ```js // today function util(ref) { if (ref.prop === 1) ref.method(2); } // tomorrow? function util({prop, ::method}) { if (prop === 1) method(2); } ``` Such shortcut would

Re: Async iterator destructuring?

Hi, > It might be useful on some occasions to [collect] async iterators [into an > array]. No need for destructuring or spreading here. The iterator helpers proposal <https://github.com/tc39/proposal-iterator-helpers> already covers these: ```js return Buffer.concat(await someStream

Re: Async iterator destructuring?

But is it not enough to do that? ```js const [item] = await db.scan({ ... ``` On Fri, 7 Feb 2020 at 23:50, Isiah Meadows wrote: > It might be useful on some occasions to destructure async iterators. For > the sake of example, I'm using `await [...]` as the syntax, but I'm by no > means

Async iterator destructuring?

It might be useful on some occasions to destructure async iterators. For the sake of example, I'm using `await [...]` as the syntax, but I'm by no means married to it. 1. Collecting a Node stream into a buffer: ```js const await [...buffers] = someStream.setEncoding('buffer') return

Re: Re: Null-coalescing default values in destructuring

] === null) o[key] = void 0; return o } convertJSONNullToUndefined(input_json_string); // do destructuring stuff ``` ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Null-coalescing default values in destructuring

The bytes used for code can be reduced. Used redundancy in the original code to handle both cases at the actual examples at OP. ```JSON.stringify()``` and ```replace()``` could be used. The original proposal mentions ```JSON```, though includes the case of ``` const { y =? 'a' } = { y: undefined

Re: Re: Null-coalescing default values in destructuring

> Given input valid JSON JSON.parse() or JSON.stringify() replacer function can > be utilized to substitute "undefined" for null. guest271314, that’s a lot of code! It feels like if anything, your example backs up the proposal. > `const { z =? 'a' } = { z: null };` I’m not sure I like the

Re: Null-coalescing default values in destructuring

I'd like to propose > > ```js > const { x =? 'a' } = {}; // z === 'a' > const { y =? 'a' } = { y: undefined }; // z === 'a' > const { z =? 'a' } = { z: null }; // z === 'a' > ``` > Which would handle also null values in default cases > > This is because default des

Null-coalescing default values in destructuring

=? 'a' } = { z: null }; // z === 'a' ``` Which would handle also null values in default cases This is because default destructuring introduced in ES6 doesn't handle null values, null values in JSON are quite common from APIs, it'd be convenient It's also inspired by the null-coalescing operator https

Re: Destructuring for Array-like objects

gt; > On Fri, Mar 22, 2019 at 10:32 AM guest271314 > wrote: > >> >> If gather the expected result correctly object destructuring can be used >> >> const {0: a, 1: b} = {0: a, 1: b, length: 2} >> > > var a = "testa", b="testb"; const

Re: Destructuring for Array-like objects

On Fri, Mar 22, 2019 at 10:32 AM guest271314 wrote: > > If gather the expected result correctly object destructuring can be used > > const {0: a, 1: b} = {0: a, 1: b, length: 2} > var a = "testa", b="testb"; const {0: c, 1: d} = {0: a, 1: b, length: 2}

Re: Destructuring for Array-like objects

If gather the expected result correctly object destructuring can be used const {0: a, 1: b} = {0: a, 1: b, length: 2} On Wed, Mar 20, 2019 at 12:59 AM Sultan wrote: > Afford array destructuring to Array-like objects. > > const [a, b] = {0: a, 1: b,

Re: Destructuring for Array-like objects

`const [a, b] = Array.from(anyArraylikeObject);` On Tue, Mar 19, 2019 at 7:22 PM Frederick Stark wrote: > This already works with an iterator, because array destructuring uses the > iterator protocol > > const [a, b] = { > 0: "ayy", > 1: "bee"

Re: Destructuring for Array-like objects

This already works with an iterator, because array destructuring uses the iterator protocol const [a, b] = { 0: "ayy", 1: "bee", length: 2, *[Symbol.iterator]() { let i = 0; while (i < this.length) { yield this[i] i++ } }, }; On Mar 20 2019, at 11:59 am, Sultan

Re: Destructuring for Array-like objects

Why is that any different or better than const [a, b] = [a, b] ? On Tue, Mar 19, 2019 at 7:59 PM Sultan wrote: > Afford array destructuring to Array-like objects. > > const [a, b] = {0: a, 1: b, length: 2} > > > ___ > es-disc

Destructuring for Array-like objects

Afford array destructuring to Array-like objects. const [a, b] = {0: a, 1: b, length: 2} ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Destructuring instances with private fields

I can make it work work under my proposal-object-members by making '#' a postfix unary operator, but then it would have to be a syntax error to use it that way unless we're dealing with a destructuring operation. That just opens up too many ways to abuse it and leak the private container. So

Re: Destructuring instances with private fields

te fields. Further, under proposal-class-fields > private fields are restricted to just `class` instances, so the > destructuring syntax doesn't make sense for that scenario. Basically it > would imply that the following is true: > > ```js > let bar1 = "bar", bar2;

Re: Destructuring instances with private fields

they possibly be destructured? There's no programmatically exposed listing of the private fields. Further, under proposal-class-fields private fields are restricted to just `class` instances, so the destructuring syntax doesn't make sense for that scenario. Basically it would imply that the following

Destructuring instances with private fields

currently be illegal syntax if `bar` is declared to be private: ```js class Foo { #bar = 1; method() { const { #bar } = this; /* … */ } } ``` How is the destructuring assignment supposed to behave anyway? Introduce a local `bar` binding

Re: Destructuring into object

Yes, I've read it, but I doesn't find something like this: target.{a,b,c} = srcObject Thank You! - Alexander Shvets https://github.com/transpiling/destructuring-into-object ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org

Re: Destructuring into object

I presume you've read the historical threads on this topic, which go back several years. Bob On Mon, Feb 26, 2018 at 11:04 AM, Alexander Shvets <quadrat...@gmail.com> wrote: > # The Problem > > ES6 destructuring syntax isn't very readable and useful, especially for > assig

Destructuring into object

# The ProblemES6 destructuring syntax isn't very readable and useful, especially for assigning to properties of existing object: // ES6 ({    a: target.a,    b: target.b,    c: target.c, } = srcObject); // Versus ES3 target.a = srcObject.a; target.b = srcObject.b; target.c = srcObject.c

Re: Suggestion: Destructuring object initializer.

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,

Re: Suggestion: Destructuring object initializer.

That was mentioned in the V8 bug, so I'm aware. (I left that implied, thinking others would catch on.) - 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 Wed, Feb 14, 2018 at 12:06 AM, Bob

Re: Suggestion: Destructuring object initializer.

There currently are *not*, and I can tell you that the suggested optimization for `Object.assign` would be substantially more complex. It's possible they may turn down the `Object.assign` optimization until later, also - they *don't* perform optimizations based on the way a function is called

Re: Suggestion: Destructuring object initializer.

performance* differences > once spread support matures (last I checked, a couple of months ago, I was > surprised to find the fairly-new spread was markedly slower than > `Object.assign`, but presumably that will change as the new stuff beds in). > But they *are* differences. > >

Re: Suggestion: Destructuring object initializer.

On Wed, Feb 14, 2018 at 7:03 AM, Raul-Sebastian Mihăilă < raul.miha...@gmail.com> wrote: > > On Wed, Feb 14, 2018 at 8:25 AM, Bob Myers wrote: >> >> For example, I did a quick test comparing `[1, 2]` and >>`new Array(1, 2)` and found that performance was identical, in >> spite of

Re: Suggestion: Destructuring object initializer.

100% identical in every way. -- T.J. Crowder [1]: https://esdiscuss.org/topic/suggestion-destructuring-object-initializer#content-13 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion: Destructuring object initializer.

On Wed, Feb 14, 2018 at 8:25 AM, Bob Myers wrote: > > > For example, I did a quick test comparing `[1, 2]` and `new Array(1, 2)` > and found that performance was identical, in spite of the claimed > inefficiency supposedly introduced by the need to look up `Array`. > > I'm curious

Re: Suggestion: Destructuring object initializer.

On Wed, Feb 14, 2018 at 8:25 AM, Bob Myers wrote: > > > With regard to the issue of the empty object inheriting a setter, my we're > really clutching at straws here. > > Really? I was simply informing you that `Object.assign({}, a, b)` is not equivalent to `{...a, ...b}`.

Re: Suggestion: Destructuring object initializer.

Actually, I did understand what he said. I didn't respond because it was obviously wrong. For example, I did a quick test comparing `[1, 2]` and `new Array(1, 2)` and found that performance was identical, in spite of the claimed inefficiency supposedly introduced by the need to look up `Array`.

Suggestion: Destructuring object initializer.

Bob, it's not clear that you understood what Alexander said about the lookup. Object.assign contains 2 names. 'Object' needs to be looked up in all the execution contexts chain, starting with the current execution context, until the global Object function is found. Then the 'assign' property must

Re: Suggestion: Destructuring object initializer.

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

Re: Suggestion: Destructuring object initializer.

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.

Re: Suggestion: Destructuring object initializer.

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

Re: Suggestion: Destructuring object initializer.

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

Re: Suggestion: Destructuring object initializer.

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

Re: Suggestion: Destructuring object initializer.

few characters or lines". >>>> But more than one recent language feature also falls into this category of >>>> mainly or purely sugar and brevity. For instance, property spread syntax is >>>> pretty much just sugar for `Object.assign`, yet every

Re: Suggestion: Destructuring object initializer.

spread syntax is >>> pretty much just sugar for `Object.assign`, yet everyone seems to think >>> it's the best thing since sliced bread. >>> >> >> My understanding of this differs: >> >> - It was to bring feature parity with array spread destructuring.

Re: Suggestion: Destructuring object initializer.

read syntax is >> pretty much just sugar for `Object.assign`, yet everyone seems to think >> it's the best thing since sliced bread. >> > > My understanding of this differs: > > - It was to bring feature parity with array spread destructuring. > - The proposal included both merging a

Re: Suggestion: Destructuring object initializer.

A big thing in a programming language for me is "glanceability" (ability to glance at code and discern roughly what's going on). Allowing destructuring braces to be mixed in object literals may well be a natural extension of destructuring: I'm not denying that. I just think

Re: Suggestion: Destructuring object initializer.

I had the same concern at first about confusing the destructuring braces with a nested object literal. After looking at it some more it seems like a natural extension of destructuring assignment. ___ es-discuss mailing list es-discuss@mozilla.org

Re: Suggestion: Destructuring object initializer.

tion-code to leverage existing good-enough data-structures like sqlite3 into a UX solution like a persistent amazon shopping-cart, or facebook image-uploader. destructuring doesn’t solve UX problems or add value to employers hiring javascript-programmers. its a negative-productivity language-fe

Re: Suggestion: Destructuring object initializer.

sign`, yet everyone seems to think > it's the best thing since sliced bread. > My understanding of this differs: - It was to bring feature parity with array spread destructuring. - The proposal included both merging and extracting. - It actually optimized for an exceptionally common case (Re

Re: Suggestion: Destructuring object initializer.

> write a Babel plugin As far as I know, the plugin architecture to Babylon, Babel's parser, is not open, and the parser cannot be extended. What is open to regular people is the ability to write Babel plugins to analyze or transform the AST. The only alternative for new syntax at the moment

Re: Suggestion: Destructuring object initializer.

this syntax. But now we have spread properties, so we could write ``` {...p.{p1, p2}, ...q.{q1, q2}} ``` But there was another consideration, which was consistency of syntax between picking (destructuring) into variables, versus picking into objects. Since ES6 we have had the `{p2, p2} = p

Re: Suggestion: Destructuring object initializer.

Sorry sent by accident before my message was edited properly. My basic point was that since curly braces are used for both destructuring and object literals, there's an issue with being able to glance at the code and quickly discern what's happening if they are mixed together in the same piece

Re: Suggestion: Destructuring object initializer.

I'm not a TC39 member, but I have a little readability issue with destructuring inside an object: ```js { {p1, p2} = p, {q1, q2} = q } ``` has a very different meaning than ```js { p: {p1, p2}, {q1, q2} = q } ``` On Fri, 9 Feb 2018 at 16:55 Bob Myers <r...@gol.com> wrote: > Thanks

Re: Suggestion: Destructuring object initializer.

1, p2: p.p2, q1:q.q1, p2: q.q2}; ``` becomes ``` return { {p1, p2} = p, {q1, q2} = q }; ``` Yes, it's pretty much sugar--no brand new functionality here. It's about brevity and expressiveness, which seems to have been a low enough bar for several other features to pass. It steals no new symbols. It clearly le

Re: Suggestion: Destructuring object initializer.

vernance process, which gives entirely new meaning to the >> notion of "design by committee", makes it impossible to find the champion >> which is the gating factor for the entire process. >> >> Bob >> >> On Thu, Feb 8, 2018 at 3:15 PM, Yeong-u K

Re: Suggestion: Destructuring object initializer.

impossible to find the champion > which is the gating factor for the entire process. > > Bob > > On Thu, Feb 8, 2018 at 3:15 PM, Yeong-u Kim <wlzla...@naver.com> wrote: > >> # Suggestion: Destructuring object initializer. >> >> ------ >> >

Re: Suggestion: Destructuring object initializer.

ss, which gives entirely new meaning to the notion of "design by committee", makes it impossible to find the champion which is the gating factor for the entire process. Bob On Thu, Feb 8, 2018 at 3:15 PM, Yeong-u Kim <wlzla...@naver.com> wrote: > # Suggestion: Destructuring object i

Suggestion: Destructuring object initializer.

# Suggestion: Destructuring object initializer. -- Destructuring assignment: it extracts values by destructuring an object, and assign _them_ to ‘variables.’ I suggest Destructuring object initialization syntax; it is similar to Destructuring assignment, except that it initializes

Re: Declaration types inside destructuring declarations

, but inelegant. I suspect it's also not identical semantics, with getters being called different numbers of times and things, which is mostly irrelevant but could matter for optimizations. Or maybe destructuring assignment is specced to be identical, I don't know. The array ones are pretty

Re: Declaration types inside destructuring declarations

And why not just use ```js const result = complexExpression(); const {a} = result; let {b} = result; ``` and with arrays: ```js const result = complexExpression(); const a = result[0]; let b = result[2]; ``` If nothing else references `result`, it can be garbage-collected. I don't see the

Re: Declaration types inside destructuring declarations

On 07/03/2017 12:25 PM, Jordan Harband wrote: ``` const { a } = o; let { b } = o; b = 1; ``` seems like a much simpler workaround than adding this complexity to the language. I dunno. I've wanted this numerous times. The use case is really const { a, let b } = complexExpression(); A

Re: Declaration types inside destructuring declarations

``` const { a } = o; let { b } = o; b = 1; ``` seems like a much simpler workaround than adding this complexity to the language. Given your two examples, I'd find it bizarre for one to work and the other not, so we'd want to support both. It also raises the question of declaration-less

Declaration types inside destructuring declarations

Totally minor, but ``` const {a, b} = o; b = 1; ``` Complains that `b` is `const` and can't be assigned. ``` let {a, b} = o; b = 1; ``` Now lint complains that `a` is never modified, and ought to be `const`. So I would like to write: ``` const {a, let b} = o; b = 1; or alternatively

Re: Strawman: Complete array and object destructuring

d make the >> most sense to assign `a` first then `c` then `b` would be whatever is >> left over. >> >> On 3/29/17, Paul Whipp <paul.wh...@gmail.com> wrote: >> > Thanks Jordan, as you describe iterable destructuring, it makes >> > impl

Re: Strawman: Complete array and object destructuring

lt;paul.wh...@gmail.com> wrote: > > Thanks Jordan, as you describe iterable destructuring, it makes > > implementation sense. > > > > The square brackets (and documentation eg: > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/ > Reference/Operato

Re: Strawman: Complete array and object destructuring

` would be whatever is left over. On 3/29/17, Paul Whipp <paul.wh...@gmail.com> wrote: > Thanks Jordan, as you describe iterable destructuring, it makes > implementation sense. > > The square brackets (and documentation eg: > https://developer.mozilla.org/en-US/docs/Web/JavaScrip

Re: Strawman: Complete array and object destructuring

Thanks Jordan, as you describe iterable destructuring, it makes implementation sense. The square brackets (and documentation eg: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) had me thinking of it as destructuring into an array

Re: Strawman: Complete array and object destructuring

The reason this doesn't work is because `...` in this context is not array destructuring - it's *iterable* destructuring. When you spread a string, you don't get each code unit, you get each code *point* - and similarly, you can spread any iterator, array or not, and collect items from

Strawman: Complete array and object destructuring

The ... destructuring for arrays is an excellent improvement that makes javascript code more readable and robust. On seeing the syntax for the first time I expected to be able to use it more completely. For example: ```js const [column, ...restOfColumns] = columns; const objProps

Re: Destructuring object outside of var declaration

On 11/13/2016 12:33 PM, Isiah Meadows wrote: > Okay. Is it a spec bug then? Throwing a ReferenceError is surprising and odd > IMHO. I think so -- having different sorts of early errors makes it a little less clear what sort of error should be thrown when two early errors of different types are

Re: Destructuring object outside of var declaration

On 11/15/16 1:57 PM, Claude Pache wrote: My guess is that Thaddee Tyl was confused by a Chrome DevTools feature, as in: I considered that, but I actually got consistent results both in Chrome's console and in a webpage... -Boris ___ es-discuss

Re: Destructuring object outside of var declaration

> Le 14 nov. 2016 à 22:53, Boris Zbarsky a écrit : > >> On 11/13/16 1:28 PM, Thaddee Tyl wrote: >>var foo, bar; >>{foo, bar} = {foo: 2, bar: 3}; >> >> is a "SyntaxError: expected expression, got '='" in Firefox, and *it >> works in Google Chrome*. > > I get

Re: Destructuring object outside of var declaration

On 11/13/16 1:28 PM, Thaddee Tyl wrote: var foo, bar; {foo, bar} = {foo: 2, bar: 3}; is a "SyntaxError: expected expression, got '='" in Firefox, and *it works in Google Chrome*. I get "Uncaught SyntaxError: Unexpected token =" in Chrome "56.0.2914.3 dev" and in Chrome "54.0.2840.9"

Re: Destructuring object outside of var declaration

Okay. Is it a spec bug then? Throwing a ReferenceError is surprising and odd IMHO. On Sun, Nov 13, 2016, 14:45 Allen Wirfs-Brock wrote: > On Nov 13, 2016, at 10:49 AM, Isiah Meadows > wrote: > > Firefox likely has a parser bug (it should never

Re: Destructuring object outside of var declaration

> On Nov 13, 2016, at 10:49 AM, Isiah Meadows wrote: > > Firefox likely has a parser bug (it should never throw a ReferenceError in > that situation). > > FireFox is correct, Chrome is wrong. See the second early error rule at

Re: Destructuring object outside of var declaration

er 17, 2013 10:06 AM > >> I'm wondering what the best syntax is for object destructuring outside > of > >> a var declaration. For instance, the following works in Firefox > Nightly and > >> Traceur: > >> > >> […] > >> > >>

Re: Destructuring object outside of var declaration

2013 at 4:27 PM, Brendan Eich <bren...@mozilla.com> wrote: > >> Nathan Wall <mailto:nathan.w...@live.com> > >> September 17, 2013 10:06 AM > >> I'm wondering what the best syntax is for object destructuring outside > of > >> a var declarat

Re: Destructuring object outside of var declaration

On Tue, Sep 17, 2013 at 4:27 PM, Brendan Eich <bren...@mozilla.com> wrote: >> Nathan Wall <mailto:nathan.w...@live.com> >> September 17, 2013 10:06 AM >> I'm wondering what the best syntax is for object destructuring outside of >> a var declaration. For inst

Re: Array tail destructuring

t;> is even observable, so you shouldn't be able to tell that an item is >> appended only after later items are pulled from the source iterator. >> >> I'm similarly confused by the wording you're using, tho, which >> suggests there may be a deeper communication mismatch -

Re: Array tail destructuring

ote: > >> I didn't understand everything discussed above, but to me, the only >> asymmetry between head and tail destructuring is for infinite iterators: >> >> `var [x] = neverEndingIterator` vs `var [...a, x] = neverEndingIterator >> // fails` >> > > Read the

Re: Array tail destructuring

On Tue, Oct 4, 2016 at 7:12 AM, Cyril Auburtin <cyril.aubur...@gmail.com> wrote: > I didn't understand everything discussed above, but to me, the only > asymmetry between head and tail destructuring is for infinite iterators: > > `var [x] = neverEndingIterator

Re: Array tail destructuring

I didn't understand everything discussed above, but to me, the only asymmetry between head and tail destructuring is for infinite iterators: `var [x] = neverEndingIterator` vs `var [...a, x] = neverEndingIterator // fails` in other cases plain arrays are quite symmetrical, they can be iterated

Re: Array tail destructuring

ke it wouldn't be. So, another thing to deal with, I guess > > I'm similarly confused by the wording you're using, tho, which > suggests there may be a deeper communication mismatch - there's no > "iterator produced for `...a`". The ...a just indicates that you need > to pull on the it

Re: Array tail destructuring

d by the wording you're using, tho, which > suggests there may be a deeper communication mismatch - there's no > "iterator produced for `...a`". The ...a just indicates that you need > to pull on the iterator being assigned to the destructuring pattern, > and store th

Re: Array tail destructuring

to solve: > > Correct. > > > The ...a just indicates that you need to pull on the iterator being > assigned to the destructuring pattern, and store the results that aren't > claimed by other parts of the destructuring pattern into "a". > > Yes, exactly. I'd understand

Re: Array tail destructuring

lve: Correct. > The ...a just indicates that you need to pull on the iterator being assigned to the destructuring pattern, and store the results that aren't claimed by other parts of the destructuring pattern into "a". Yes, exactly. I'd understand the issue better if "a" had t

Re: Array tail destructuring

ems are pulled from the source iterator. I'm similarly confused by the wording you're using, tho, which suggests there may be a deeper communication mismatch - there's no "iterator produced for `...a`". The ...a just indicates that you need to pull on the iterator being assigned to the

Re: Array tail destructuring

On Oct 2, 2016, at 10:50 AM, Awal Garg wrote: >> On Oct 2, 2016, at 9:30 AM, Olivier Lalonde wrote: >> >> So what's the problem with `[...a, last]` that `[...a]` doesn't have? I >> still don't get it. > > > Since you don’t know when the iterator

Re: Array tail destructuring

On Oct 2, 2016, at 9:30 AM, Olivier Lalonde wrote: So what's the problem with `[...a, last]` that `[...a]` doesn't have? I still don't get it. > Since you don’t know when the iterator produced for `…a` will terminate, there’s no way to know when you need to stop iterating

Re: Array tail destructuring

finite ones: > ``` > function* ones(){ while(true) yield 1; } > var [...a]=ones(); // freezes > ``` > > > 2016-10-01 18:24 GMT+02:00 Dmitry Soshnikov <dmitry.soshni...@gmail.com > <mailto:dmitry.soshni...@gmail.com>>: > Yeah, because it's not a pattern patching,

  1   2   3   4   5   >