Re: Array tail destructuring

GMT+02:00 Dmitry Soshnikov <dmitry.soshni...@gmail.com> >>> : >>> >>>> Yeah, because it's not a pattern patching, and access to array elements >>>> may have side effects, it's seems hard to specify/implement. Otherwise, >>>> destructurin

Re: Array tail destructuring

18:24 GMT+02:00 Dmitry Soshnikov <dmitry.soshni...@gmail.com>: >> >>> Yeah, because it's not a pattern patching, and access to array elements >>> may have side effects, it's seems hard to specify/implement. Otherwise, >>> destructuring might analyze the pat

Re: Array tail destructuring

Dmitry Soshnikov <dmitry.soshni...@gmail.com>: > >> Yeah, because it's not a pattern patching, and access to array elements >> may have side effects, it's seems hard to specify/implement. Otherwise, >> destructuring might analyze the pattern, see the last element is

Re: Array tail destructuring

elements > may have side effects, it's seems hard to specify/implement. Otherwise, > destructuring might analyze the pattern, see the last element is required, > extract it, and then do iteration for others. > > Dmitry > > > On Saturday, October 1, 2016, Michael Theriot

Re: Array tail destructuring

Yeah, because it's not a pattern patching, and access to array elements may have side effects, it's seems hard to specify/implement. Otherwise, destructuring might analyze the pattern, see the last element is required, extract it, and then do iteration for others. Dmitry On Saturday, October 1

Re: Array tail destructuring

I think this is because there's no universal way of determining when an iterator ends. The only way this could work for all iterators would require popping values off of `a` after they've been added. On Sat, Oct 1, 2016 at 6:17 AM, Cyril Auburtin wrote: > It was

Array tail destructuring

It was possibly already discussed, but why isn't: ``` var [...a, last] = [1,2,3]; ``` supported? I don't see the problem, as long as there's one ... only ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Destructuring default values with empty strings

I think an appropriate map call will let you do anything you want here. On Mar 27, 2016 4:51 AM, "Cyril Auburtin" wrote: > when doing let [tag = 'cat', ...cls] = '.foo.bar'.split('.') > > I'd find it more logical to use the default value for all falsy values > like an

Destructuring default values with empty strings

when doing let [tag = 'cat', ...cls] = '.foo.bar'.split('.') I'd find it more logical to use the default value for all falsy values like an empty string '' for the tag variable. but the default value isn't applied there ___ es-discuss mailing list

Re: Destructuring an object into a new object (like Underscore pick but ESier)

In my proposal, there are two syntaxes related to "deep" or "nested" picking. Assuming: ```js var obj = {a: {b: 1, c: 2}, d: 3}; ``` Inside the picking construct, the dot does a "deep pick": ``` obj.{a.b} // { b: 1 } ``` The colon does a "nested pick": ``` obj.{a: {b}} // { a: {b: 1}} ```

Re: Destructuring an object into a new object (like Underscore pick but ESier)

Viktor Kronvall schrieb: What would this do? ``` let newObj = {obj.a.b} ``` `{a: {b: obj.a.b}}` or `{a: obj.a.b}`? Or should nested property access be disallowed? Neither - `obj.a.b` is `(obj.a).b`, so it's equivalent to `let newObj = {b: obj.a.b}`. The spec would basically be something

Re: Destructuring an object into a new object (like Underscore pick but ESier)

Zacqary Adam Xeper wrote: But if I want to initialize a new object that pulls in just the foo and bar properties, I have to type this whole structure out: let newObj = {foo: obj.foo, bar: obj.bar, quux: 4} Or, if I want to use shorthand property names, I can use a destructuring statement

Re: Destructuring an object into a new object (like Underscore pick but ESier)

I like how your pick notation can combine easily with spread operators: let newObj = { ...obj.{foo, bar}, quux: 4} I think I actually prefer that to mine. Destructuring on the left side of a colon is sort of fighting against the spread operator, and might suggest a more natural syntax

Re: Destructuring an object into a new object (like Underscore pick but ESier)

t the foo and >> bar properties, I have to type this whole structure out: >> let newObj = {foo: obj.foo, bar: obj.bar, quux: 4} >> >> Or, if I want to use shorthand property names, I can use a destructuring >> statement, but then I have to type all the property n

Re: Destructuring an object into a new object (like Underscore pick but ESier)

> > I can create a new object with ALL of these properties using a spread > operator: > let newObj = {...obj, quux: 4} > Let's not do this. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Destructuring an object into a new object (like Underscore pick but ESier)

s whole structure out: > let newObj = {foo: obj.foo, bar: obj.bar, quux: 4} > > Or, if I want to use shorthand property names, I can use a destructuring > statement, but then I have to type all the property names twice: > let {foo, bar} = obj; > let newObj = {foo, bar, quux: 4}; > &g

Destructuring an object into a new object (like Underscore pick but ESier)

object that pulls in just the foo and bar properties, I have to type this whole structure out: let newObj = {foo: obj.foo, bar: obj.bar, quux: 4} Or, if I want to use shorthand property names, I can use a destructuring statement, but then I have to type all the property names twice: let {foo, bar

Destructuring: Add early errors for empty patterns?

Hi all, In playing with destructuring, it seems like there are some syntax gotchas that really should trigger some sort of error and instead fail silently. For instance: ``` let {} = foo; ``` This line does absolutely nothing and is most likely an error on the developer's part. However

Re: Destructuring: Add early errors for empty patterns?

gt; > Herby > > Standards Zakas wrote: > >> Hi all, >> >> In playing with destructuring, it seems like there are some syntax >> gotchas that really should trigger some sort of error and instead fail >> silently. For instance: >> >> ```

Re: Destructuring: Add early errors for empty patterns?

assignments and they would need to parse it for "emptiness"); not consistent if special cases are errors. Herby Standards Zakas wrote: Hi all, In playing with destructuring, it seems like there are some syntax gotchas that really should trigger some sort of error and instead fai

Re: Destructuring: Add early errors for empty patterns?

On 21 October 2015 at 20:19, Standards Zakas <standa...@nczconsulting.com> wrote: > In playing with destructuring, it seems like there are some syntax gotchas > that really should trigger some sort of error and instead fail silently. For > instance: > > ``` > let {} = foo;

Re: Import statements & destructuring

'./config'; > console.log(config.api.host); > > // or else (typically this is what one would expect when importing > some older modules through Babel) > // but I am not entirely sure this would work for real with ES2015 > import {api} from './config'; > console.log(api.hos

Import statements & destructuring

, wouldn't it be useful to be able to use destructuring within import statement as you would with objects: ```js import {api: {host}} from './config'; console.log(host); ``` I guess this does not work for static evaluation reasons but I just want to be sure this is it or if there are more obvious/profound

Re: Reified lvalue (was: Re: Extensible destructuring proposal)

: The main idea is, that if object defines `Symbol.get` method, it gets used to access properties of object instead of `[]` when destructuring. Aw, when I read extensible destructuring I had hoped to see an extension to the destructuring syntax, not to see how

Reified lvalue (was: Re: Extensible destructuring proposal)

Bergi wrote: Samuel Hapák schrieb: The main idea is, that if object defines `Symbol.get` method, it gets used to access properties of object instead of `[]` when destructuring. Aw, when I read extensible destructuring I had hoped to see an extension to the destructuring syntax, not to see

Re: Reified lvalue (was: Re: Extensible destructuring proposal)

wrote: Samuel Hapák schrieb: The main idea is, that if object defines `Symbol.get` method, it gets used to access properties of object instead of `[]` when destructuring. Aw, when I read extensible destructuring I had hoped to see an extension to the destructuring syntax, not to see how

Re: Extensible destructuring proposal

a custom destructuring syntax. Maybe something like this: I intentionally did not bring up pattern matching. That indeed is what views are usually wanted for. But then you need to be much more careful in designing a mechanism that avoids re

Re: Extensible destructuring proposal

Objects. ii) If so, how to proceed with simplifying destructuring for these data structures. Let's discuss the i) first. On 4.8.2015, at 14:26, Andreas Rossberg rossb...@google.com wrote: As for a more Scala-like variant with distinguished syntax, I'm fine with that semantically. But I still

Re: Extensible destructuring proposal

. This would probably be a little more justifiable IMHO than merely a custom destructuring syntax. Maybe something like this: ```js Type[Symbol.pattern] = (obj) = { return [obj.a, obj.b]; } const Other = { [Symbol.pattern]: obj = obj, } class None { static [Symbol.pattern](obj

Re: Extensible destructuring proposal

be a great stepping stone to a limited pattern matching syntax. This would probably be a little more justifiable IMHO than merely a custom destructuring syntax. Maybe something like this: I intentionally did not bring up pattern matching. That indeed is what views are usually wanted

Re: Extensible destructuring proposal

destructuring syntax. Maybe something like this: I intentionally did not bring up pattern matching. That indeed is what views are usually wanted for. But then you need to be much more careful in designing a mechanism that avoids re-transforming the scrutinee for every tested case! Because

Re: Extensible destructuring proposal

Thank you for your reply Andreas! So, let's split this discussion into two parts: i) Whether there is a good use case for non-standard data structures like Immutable.js in place of standard Objects. ii) If so, how to proceed with simplifying destructuring for these data structures. Let's

Re: Extensible destructuring proposal

On 31 July 2015 at 20:09, Samuel Hapák samuel.ha...@vacuumapps.com wrote: So, do you still have objections against this proposal? Could we summarize them? @Andreas, do you still think that there is category error involved? If you want to overload existing object pattern syntax, then yes,

Re: Extensible destructuring proposal

So, do you still have objections against this proposal? Could we summarize them? @Andreas, do you still think that there is category error involved? Thanks, Samuel smime.p7s Description: S/MIME cryptographic signature ___ es-discuss mailing list

Re: Extensible destructuring proposal

Announcing babel-plugin: https://www.npmjs.com/package/babel-plugin-extensible-destructuring https://www.npmjs.com/package/babel-plugin-extensible-destructuring Samuel smime.p7s Description: S/MIME cryptographic signature ___ es-discuss mailing list

Re: Extensible destructuring proposal

I think the example actually reveals a deeper issue with the motivation: the desire to destructure maps like here is rooted in a category error. Destructuring is designed to apply to objects from the program domain, while maps are typically meant to encode data from the problem domain

Re: Extensible destructuring proposal

I too am fond of Scala's extensible pattern matching. Before I knew about Scala's approach, I thoughtlessly agreed with the conventional wisdom that pattern matching and object-oriented programming are necessarily at odds. Letting objects define their own destructuring semantics shows that wisdom

Re: Extensible destructuring proposal

On 21.7.2015, at 16:23, Bergi a.d.be...@web.de wrote: Aw, when I read extensible destructuring I had hoped to see an extension to the destructuring syntax, not to see how semantics of destructuring objects are changed. Thanks Bergi, I find your idea really interesting. If get

Re: Extensible destructuring proposal

On 21.7.2015, at 12:42, Claude Pache claude.pa...@gmail.com wrote: For example, one can imagine something like: ```js const {author: {name: {first, last}, birthdate}} = book.toObject() ``` There are two issues I see here: - `book.toObject()` would have to do deep conversion and you

RE: Extensible destructuring proposal

From: Samuel Hapák [mailto:samuel.ha...@vacuumapps.com] Could you please explain it on example? Let’s say I have ``` let book = Map{author: {name: “John”, surname: “Doe”}, birthdate: “10-10-1990”}; ``` How would you extract `birthdate`? How would you extract `name`? Your syntax here

Re: Extensible destructuring proposal

Domenic Denicola schrieb: For maps you can just do ```js const [[k1, v1], [k2, v2], ...rest] = map.entries(); ``` The problem with this is that you would need to know the order of the keys in the map. Your code does only extract the first and second key-value pairs, allowing us to get the

Re: Extensible destructuring proposal

my primary goal (indeed most data structures would have only a single extractor). The main benefits I see are: * explicit is better than implicit * works anywhere in a destructuring pattern, not only the topmost level * can be chosen not to be used (e.g. for `let {size} = myMap;`) The only

Re: Extensible destructuring proposal

Well, the spec says they are ordered, so I'm not sure where you're getting that from. From: Bergi a.d.be...@web.de Sent: Jul 21, 2015 8:53 AM To: Domenic Denicola; es-discuss Subject: Re: Extensible destructuring proposal Domenic Denicola schrieb: For maps you can just do ```js const

Re: Extensible destructuring proposal

Ben Newman schrieb: That said, virtually every time I've written an unapply or unapplySeq method in Scala, it has been with multi-case pattern matching in mind, and we're only talking about destructuring assignment here, which I suppose is like a single-case pattern match. Right, we don't

Re: Extensible destructuring proposal

On 21.7.2015, at 15:09, Domenic Denicola d...@domenic.me wrote: For maps you can just do ```js const [[k1, v1], [k2, v2], ...rest] = map.entries(); ``` There is no need to add more complexity to object destructuring (which should only be used for objects and their string keys

Re: Extensible destructuring proposal

I think the example actually reveals a deeper issue with the motivation: the desire to destructure maps like here is rooted in a category error. Destructuring is designed to apply to objects from the program domain, while maps are typically meant to encode data from the problem domain

Re: Extensible destructuring proposal

Domenic Denicola schrieb: Well, the spec says they are ordered, so I'm not sure where you're getting that from. Yes, the spec defines an order to make iteration predictable and consistent, but that doesn't mean anyone would use a `Map` for an ordered structure. I would consider new

Re: Extensible destructuring proposal

On 21.7.2015, at 17:19, Domenic Denicola d...@domenic.me wrote: From: Samuel Hapák [mailto:samuel.ha...@vacuumapps.com] Could you please explain it on example? Let’s say I have ``` let book = Map{author: {name: “John”, surname: “Doe”}, birthdate: “10-10-1990”}; ``` How would

Re: Extensible destructuring proposal

On 21.7.2015, at 20:16, Andreas Rossberg rossb...@google.com wrote: Or, in other words: destructuring is only useful when you know the keys at programming time (i.e., statically). But if that is the case, there is rarely a good reason to use a map. Actually, the main motivation is to use

Extensible destructuring proposal

Hello there, I have written proposal to allow extend standard behavior of object destructuring: https://github.com/vacuumlabs/es-proposals/blob/master/extensible-destructuring.md Main idea is, that currently object destructuring is useless for people who use Map or Immutable.Map (https

Re: Extensible destructuring proposal

Le 21 juil. 2015 à 08:14, Samuel Hapák samuel.ha...@vacuumapps.com a écrit : Hello there, I have written proposal to allow extend standard behavior of object destructuring: https://github.com/vacuumlabs/es-proposals/blob/master/extensible-destructuring.md Main idea is, that currently

Re: Extensible destructuring proposal

On 21 July 2015 at 08:14, Samuel Hapák samuel.ha...@vacuumapps.com wrote: I have written proposal to allow extend standard behavior of object destructuring: https://github.com/vacuumlabs/es-proposals/blob/master/extensible-destructuring.md Main idea is, that currently object destructuring

Re: Extensible destructuring proposal

On 21.7.2015, at 9:34, Andreas Rossberg rossb...@google.com wrote: People reading code will (rightfully) expect destructuring to be syntactic sugar for property access. I don't think it's worth breaking that equivalence. If you want user-defined patterns then they should

RE: Extensible destructuring proposal

For maps you can just do ```js const [[k1, v1], [k2, v2], ...rest] = map.entries(); ``` There is no need to add more complexity to object destructuring (which should only be used for objects and their string keys). -Original Message- From: es-discuss [mailto:es-discuss-boun

Re: Extensible destructuring proposal

Samuel Hapák schrieb: The main idea is, that if object defines `Symbol.get` method, it gets used to access properties of object instead of `[]` when destructuring. Aw, when I read extensible destructuring I had hoped to see an extension to the destructuring syntax, not to see how semantics

Re: Aliased object destructuring assignments?

```JS var {f: foo} = {f: 5}; foo == 5 // true ``` On Sun, Jun 21, 2015 at 8:50 PM, Salehen Rahman salehen.rah...@gmail.com wrote: I know that `import` allows us to alias imports, like so: ```javascript import { f as foo } from 'f'; ``` But what about object destructuring assignments

Aliased object destructuring assignments?

I know that `import` allows us to alias imports, like so: ```javascript import { f as foo } from 'f'; ``` But what about object destructuring assignments? ```javascript var { f as foo } = someObject; // Syntax error on Babel ``` Either Babel is very late in the game, or the above syntax

Re: Aliased object destructuring assignments?

: I know that `import` allows us to alias imports, like so: ```javascript import { f as foo } from 'f'; ``` But what about object destructuring assignments? ```javascript var { f as foo } = someObject; // Syntax error on Babel ``` Either Babel is very late in the game, or the above

Re: Aliased object destructuring assignments?

as foo } from 'f'; ``` But what about object destructuring assignments? ```javascript var { f as foo } = someObject; // Syntax error on Babel ``` Either Babel is very late in the game, or the above syntax is actually not supported in ECMAScript. It would be really beneficial to support aliasing

Re: Named `this` and `this` destructuring

On Wed, Jun 17, 2015 at 11:38 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 17, 2015, at 10:01 AM, Jussi Kalliokoski wrote: ... More examples of the power of the bind syntax can be found in the links, but the bind syntax combined with my proposal would for example allow this:

Re: Named `this` and `this` destructuring

On Wed, Jun 17, 2015 at 10:35 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: OK **that one** I've no idea what supposes to improve exactly ... I should have tried to realize your proposal better, apologies. After seeing that, I probably agree with Allen at this point we don't

Re: Named `this` and `this` destructuring

OK **that one** I've no idea what supposes to improve exactly ... I should have tried to realize your proposal better, apologies. After seeing that, I probably agree with Allen at this point we don't really need that kind of syntax around JS (still IMHO, of course) Best Regards On Wed, Jun 17,

Re: Named `this` and `this` destructuring

On Jun 17, 2015, at 10:01 AM, Jussi Kalliokoski wrote: ... More examples of the power of the bind syntax can be found in the links, but the bind syntax combined with my proposal would for example allow this: ```JS function add (a, b) { return a + b; } 2::add(3) // 5 ``` and why

Re: Named `this` and `this` destructuring

the ::bind syntax is OK (I don't really like that double colon 'cause it's not semantic at all with the single colon meaning but I can live with it) but having potential bitwise-like operators around to adress a possible context ... well, I wouldn't probably use/need that in the short, or even

Re: Named `this` and `this` destructuring

On Wed, Jun 17, 2015 at 10:45 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: the ::bind syntax is OK (I don't really like that double colon 'cause it's not semantic at all with the single colon meaning but I can live with it) but having potential bitwise-like operators around to

Re: Re: Named `this` and `this` destructuring

Exactly what Allen said. Adding syntax to work around a bad feature is an awful idea. We should be trying to reduce and remove usage of `this` by reducing resistance to other ways of programming in JavaScript. Minimal API Surface areas apply to languages, not just libraries.

Named `this` and `this` destructuring

destructuring and default values (as well as type annotation in language extensions). The different forms and their desugarings: function add (a, b) { return a + b; } // would desugar to function add (b) { var a = this; return a + b; } function multiplyTuple ([a, b], multiplier) { return

Re: Named `this` and `this` destructuring

. function add (this : number, b : number) : number { return this + b; } This leads to my current proposal, i.e. being able to make the first parameter of the function an alias for `this` by using a special prefix (). This would not only allow aliasing `this`, but also destructuring and default

Re: Named `this` and `this` destructuring

parameter of the function an alias for `this` by using a special prefix (). This would not only allow aliasing `this`, but also destructuring and default values (as well as type annotation in language extensions). The different forms and their desugarings: function add (a, b) { return a + b

Re: Named `this` and `this` destructuring

I forgot to mention that those functions I use as both methods and map/filters are most of the time **private** , and yet we haven't introduced private methods within current class specification. Functions with a `this` are very portable/handy within closures, combined with Array extras and

Re: Named `this` and `this` destructuring

On Jun 17, 2015, at 8:09 AM, Andrea Giammarchi wrote: Mostly every Array extra in ES5 would work with those functions, e.g. ```js function multiplyPoints (_p2) { var { x1: x, y1: y } = this; var { x2: x, y2: y } = _p2; return { x: x1 * x2, y: y1 * y2 }; } var multiplied =

Re: Non-binding destructuring assignment

The binding identifiers are optional. You can do what you want already with: const lastOfThree = ([,, third]) = {   return third; } On Wed, Apr 29, 2015 at 12:40 PM, Elie Rotenberg e...@rotenberg.io wrote: Using array destructuring assignment and constraining linting rules, I often find

Re: Non-binding destructuring assignment

Rotenberg e...@rotenberg.io wrote: Using array destructuring assignment and constraining linting rules, I often find myself having to chose names for bindings I don't intent on using. I usually end up using a conventional ignore name, such as _ignore, which I void to shut up the linter

Non-binding destructuring assignment

Using array destructuring assignment and constraining linting rules, I often find myself having to chose names for bindings I don't intent on using. I usually end up using a conventional ignore name, such as _ignore, which I void to shut up the linter without adding exceptions. Besides the linting

Re: Non-binding destructuring assignment

e...@rotenberg.io wrote: Using array destructuring assignment and constraining linting rules, I often find myself having to chose names for bindings I don't intent on using. I usually end up using a conventional ignore name, such as _ignore, which I void to shut up the linter without adding

Re: Non-binding destructuring assignment

On Wed, Apr 29, 2015 at 4:39 AM, Elie Rotenberg e...@rotenberg.io wrote: Using array destructuring assignment and constraining linting rules, I often find myself having to chose names for bindings I don't intent on using. I usually end up using a conventional ignore name, such as _ignore, which

Re: Non-binding destructuring assignment

Andreas Rossberg wrote: I agree that we should have wildcard patterns. I also think that array elisions are a non-solution, because you need a magnifier to read or count them, Agree. and they square oddly with optional commas in the end. Old rule: allowing one (and only one) comma at end

Re: Non-binding destructuring assignment

On Wed, Apr 29, 2015 at 12:54 PM Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 29, 2015 at 4:39 AM, Elie Rotenberg e...@rotenberg.io wrote: Using array destructuring assignment and constraining linting rules, I often find myself having to chose names for bindings I don't intent

Re: Non-binding destructuring assignment

On Wed, Apr 29, 2015 at 10:44 AM, Rick Waldron waldron.r...@gmail.com wrote: Why _? A linter can just allow the end developer to define the binding name. https://github.com/jshint/jshint/issues/2352 Of course. _ is just a common name for the i don't care destructuring slot. ~TJ

Re: Trailing commas in arguments list, imports and destructuring

in function arguments lists, imports and destructuring as well: http://babeljs.io/repl/#?experimental=trueevaluate=trueloose=falsespec=falsecode=import%20%7B%0A%20%20voo%2C%0A%20%20doo%2C%0A%7D%20from%20%22.%2Fdat.js%22%3B%0A%0Alet%20%7B%0A%20%20x%2C%0A%20%20y%2C%0A%7D%20%3D%20voo%3B%0A%0Alet%20%5B

Re: Trailing commas in arguments list, imports and destructuring

...@gmail.com wrote: I just noticed that Babel support trailing commas in function arguments lists, imports and destructuring as well: http://babeljs.io/repl/#?experimental=trueevaluate=trueloose=falsespec=falsecode=import%20%7B%0A%20%20voo%2C%0A%20%20doo%2C%0A%7D%20from%20%22.%2Fdat.js%22%3B%0A

Re: Trailing commas in arguments list, imports and destructuring

Note that you’ve got the experimental REPL option enabled which means all transformers are enabled which includes the `es7.trailingFunctionCommas` one which allows trailing commas in function parameter lists and call expressions. The destructuring grammar does allow trailing commas (https

Trailing commas in arguments list, imports and destructuring

I just noticed that Babel support trailing commas in function arguments lists, imports and destructuring as well: http://babeljs.io/repl/#?experimental=trueevaluate=trueloose=falsespec=falsecode=import%20%7B%0A%20%20voo%2C%0A%20%20doo%2C%0A%7D%20from%20%22.%2Fdat.js%22%3B%0A%0Alet%20%7B%0A%20%20x

Re: Single destructuring argument to an arrow function

Really awesome if we could have this feature. On Sat, Mar 21, 2015 at 4:04 AM, Brendan Eich bren...@mozilla.org wrote: But we could extend the cover grammar with some work. You'd have to push ArrayLiteral and ObjectLiteral down from PrimaryExpression alternative right-hand sides, to live

Re: Single destructuring argument to an arrow function

But we could extend the cover grammar with some work. You'd have to push ArrayLiteral and ObjectLiteral down from PrimaryExpression alternative right-hand sides, to live under CoverParenthesizedExpressionAndArrowParameterList.Seems do-able -- anyone see a fatal problem? Not for ES6 arrows,

Re: Single destructuring argument to an arrow function

Inline... On Thu, Mar 19, 2015 at 4:50 PM Jan-Ivar Bruaroey j...@mozilla.com wrote: Hi group! First post, so be gentle. Welcome I love how arrow functions allow single arguments to be passed without parenthesis, so I expected this to work: Promise.all([true, false]).then([foo, bar]

Re: Single destructuring argument to an arrow function

But we could extend the cover grammar with some work. You'd have to push ArrayLiteral and ObjectLiteral down from PrimaryExpression alternative right-hand sides, to live under CoverParenthesizedExpressionAndArrowParameterList.Seems do-able -- anyone see a fatal problem? Could be an ES7

Single destructuring argument to an arrow function

Hi group! First post, so be gentle. I love how arrow functions allow single arguments to be passed without parenthesis, so I expected this to work: Promise.all([true, false]).then([foo, bar] = console.log(foo +”, + bar)); but it doesn't: SyntaxError: invalid arrow-function

Re: Destructuring `undefined` and `null`

see https://bugs.ecmascript.org/show_bug.cgi?id=3574 already fix in my working draft Allen On Jan 19, 2015, at 12:01 PM, Axel Rauschmayer wrote: If I understand the spec correctly, destructuring works as follows: ```js let {} = undefined; // OK??? let {x} = undefined; // TypeError

Re: Destructuring `undefined` and `null`

Allen Wirfs-Brock wrote: see https://bugs.ecmascript.org/show_bug.cgi?id=3574 already fix in my working draft Ok, so the ToObject always runs first. Sounds better on short reflection -- thanks! /be ___ es-discuss mailing list

Re: Destructuring `undefined` and `null`

basis case. /be Axel Rauschmayer wrote: If I understand the spec correctly, destructuring works as follows: ```js let {} = undefined; // OK??? let {x} = undefined; // TypeError let [] = undefined; // TypeError let [y] = undefined; // TypeError ``` Destructuring `undefined` (or `null`) via

Re: Destructuring `undefined` and `null`

/be Axel Rauschmayer wrote: If I understand the spec correctly, destructuring works as follows: ```js let {} = undefined; // OK??? let {x} = undefined; // TypeError let [] = undefined; // TypeError let [y] = undefined; // TypeError ``` Destructuring `undefined

Object Rest Destructuring and Spread Properties (Re: September 25 2014 Meeting Notes)

Sorry, but I don’t exactly get the outcome of the object destructuring discussion when it came to own vs enumerable properties. I see Allen Wirfs-Brock arguing against using only own properties, but then a few sentences later stating “ownness is clear”. Huh? FWIW, to this day I don’t get

Re: Using destructuring for function arguments

On 5/31/2014 1:54 PM, Allen Wirfs-Brock wrote: What happens here is that none of `secure`, `path`, `domain`, `expires` are defined. I can use `typeof` on them to protect against this, but then I end up with some lousy looking code: not really, the thrown exception while processing the

Re: Using destructuring for function arguments

they will be assigned. Right, and they are in scope no matter what. Seems to me that an implementation bug (can't have parameter default value for destructuring formal) is the only problem brought to light in this thread. Anyone see anything else amiss? No, seems it's the only problem. Also

Using destructuring for function arguments

I've been playing around with using destructuring as function arguments and have come across some odd behaviors that I'm not sure are intentional (or perhaps, not to spec). For context, consider the following function: ``` function setCookie(name, value, { secure, path, domain, expires

Re: Using destructuring for function arguments

Seems like any identifiers in the arguments should always be defined in scope before ever considering what they will be assigned. On May 31, 2014 11:59 AM, Nicholas C. Zakas standa...@nczconsulting.com wrote: I've been playing around with using destructuring as function arguments and have come

Re: Using destructuring for function arguments

On Sat, May 31, 2014 at 11:59 AM, Nicholas C. Zakas standa...@nczconsulting.com wrote: I've been playing around with using destructuring as function arguments and have come across some odd behaviors that I'm not sure are intentional (or perhaps, not to spec). For context, consider

Re: Using destructuring for function arguments

Nicholas C. Zakas wrote: ``` function setCookie(name, value, { secure, path, domain, expires } = {}) { console.log(secure); // ... } ``` Unfortunately, that resulted in a syntax error in Firefox. Could you please file a bug against SpiderMonkey? Thanks, /be

Re: Using destructuring for function arguments

Matthew Robb wrote: Seems like any identifiers in the arguments should always be defined in scope before ever considering what they will be assigned. Right, and they are in scope no matter what. Seems to me that an implementation bug (can't have parameter default value for destructuring

<    1   2   3   4   5   >