Re: nits on BigInt Proposal

> On Feb 10, 2018, at 12:26 AM, Isiah Meadows wrote: > > Kai, mind commenting about this in the proposal's repo (filing a new issue > there), where you'll more likely get feedback? > yea, and got feedback. turns out there’s a serious footgun [1] using string-only

Re: Suggestion: Destructuring object initializer.

Thank you for your comments. The proposed picking syntax has gone through several iterations. Way back when, we had ``` o # {a, b} ``` for picking properties `a` and `b` from `o`, resulting in `{a: o.a, b: o.b}`. That, however, would of course eat a precious symbol. So a later version replaced

Proposal: deleting properties in object initializer expression

With spread properties, it would be great to be able to remove specific properties: ```js const obj1 = { one: 1, two: 2, three: 3 }; const obj2 = { ...obj1, delete three // <-- new syntax }; ``` `obj2` would be `{ one: 1, two: 2 }`. This syntax is visually similar to the getter/setter syntax.

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 of

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 wrote: > Thanks for your

Re: try/catch/else

The idea isn't to make the second call's exceptions silent, it's not to catch them (i.e. let them propagate).On 9 Feb 2018 2:46 p.m., Augusto Moura wrote:I see this operator quite confusing, in my opinion it's a best practice treat the functions (and errors) separately.

Re: nits on BigInt Proposal

Kai, mind commenting about this in the proposal's repo (filing a new issue there), where you'll more likely get feedback? On Fri, Feb 9, 2018, 08:51 kai zhu wrote: > @bruno, i'm wondering if having a DecimalFloat128Array (based on ieee 754 > standard) is good enough for

Re: Cloning WeakSet/WeakMap

Why would they? You can put single object in *infinite* amount of WeakSets and it won't prevent it's garbage collection. On 9 Feb 2018 4:11 pm, "Michael Luder-Rosefield" wrote: > Possibly a silly question, but... > > What happens re garbage collection if you have two

Re: Cloning WeakSet/WeakMap

2018-02-09 10:05 GMT-05:00 Michał Wadas : > English isn't my native language, so I probably made a mistake. > oh ok, sorry for my misinterpretation > I was asked to add WeakSet.prototype.union(iterable) creating new WeakSet > instance including data from both iterable and

Re: Cloning WeakSet/WeakMap

English isn't my native language, so I probably made a mistake. I was asked to add WeakSet.prototype.union(iterable) creating new WeakSet instance including data from both iterable and original WeakSet. On 9 Feb 2018 4:01 pm, "David Bruant" wrote: > Hi, > > My

Re: Cloning WeakSet/WeakMap

I think this is referring to cloning a WeakSet into another WeakSet Thomas Grainger On 9 February 2018 at 15:01, David Bruant wrote: > Hi, > > My understanding is that cloning a WeakSet into a Set would remove all its > properties related to security and garbage collection.

Re: Cloning WeakSet/WeakMap

Hi, My understanding is that cloning a WeakSet into a Set would remove all its properties related to security and garbage collection. The properties related to security and garbage collection of WeakSet are based on the fact that its elements are not enumerable by someone who would only be

Cloning WeakSet/WeakMap

Hi. I was asked to include a way to clone WeakSet in Set builtins proposal. Is there any consensus on security of such operation? Michał Wadas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: nits on BigInt Proposal

@bruno, i'm wondering if having a DecimalFloat128Array (based on ieee 754 standard) is good enough for accounting (with 34 decimal-digit precision)? like existing database drivers, you can only get/set strings, but infix / inplace operators wouldn’t have that restriction. e.g.: ```javascript

Re: try/catch/else

I see this operator quite confusing, in my opinion it's a best practice treat the functions (and errors) separately. If you want to ignore the second error you can even create a `silent` helper. ```js const treatedShowSuggestions = (suggs) => { try { showSuggestions(suggs); } catch (e) {

Re: Suggestion: Destructuring object initializer.

Thanks for your input. Actually, I was not trying to beat the dead horse of my property picking proposal, but rather give advice to another would-be spec proposer based on my experience. But since you brought it up, the spec for property picking can be found at

Re: Suggestion: Destructuring object initializer.

Bob, I think it's an interesting idea too, but you can't strong-arm people into getting excited about what you're asking for. If it really is that important to you then put together a solid proposal, write a Babel plugin and then try to find a champion for it. On Thu, 8 Feb 2018 at 14:05 Bob

Re: try/catch/else

> Le 9 févr. 2018 à 00:19, Peter van der Zee a écrit : > >>> On Thu, Feb 8, 2018 at 10:13 AM, Claude Pache >>> wrote: What about the following pattern (labelled block + break)? ```js processSuggestions: { let

Re: try/catch/else

I think the best argument for having try/catch/else is that it makes it trivial to translate promises into async/await. Consider this: ``` let result = a() .then(b, c) .catch(d); ``` If we want to translate this 1:1 to try/catch/else in an async function we'll end up with something like this: