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:
> 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 suggestions;
try {
suggestions =
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 Myer
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
https://github.com/rtm/js-pick-nota
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) {
@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
a
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
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 holdin
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.
>
> The properties r
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 understanding is that cloning a
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 original WeakSet.
>
ok,
Possibly a silly question, but...
What happens re garbage collection if you have two WeakSets referencing the
same object? Do they each block that object's removal?
On Fri, 9 Feb 2018 at 15:05 Michał Wadas wrote:
> English isn't my native language, so I probably made a mistake.
>
> I was asked
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 WeakSets referencing
> the s
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 accounting (with 34 decim
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. If you want to ignore the s
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 input.
>
> Actua
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 s
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. This
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 t
> 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 interface :(
[1] https://git
20 matches
Mail list logo