RE: Alternative way to achieve cancelable promise

Thank you for your interest in my proposal. :D I also thought so and I posted [an older version of my proposal on June](https://github.com/tc39/proposal-cancelable-promises/issues/22) there. I got this answer: >This is a separate proposal, and not an issue with the proposal being >developed

Purpose of Error/Return in Iterators (And Suggestion on Improving Consumption)

I thought I’d raise a discussion on just what exactly iterators are, a simple view might be that they’re just a sequence of values which can be gotten using .next(). However this is simplified because iterators .next can actually do three things: 1. They can yield a value 2. They can

Re: Alternative way to achieve cancelable promise

I must admit that I do like this approach, however I'm not too familiar with the proposed spec to definitively comment on this. Have you tried proposing this in the https://github.com/tc39/proposal-cancelable-promises repository? That may be a better avenue for your suggestions. On Sat, Oct 15,

Re: A Result class for functions that may return errors

I agree with this: if a result may fail normally, I would just return a sentinel value like `undefined` (I usually avoid `null`). If it's truly exceptional, don't catch it except to log it/etc. On Tue, Oct 18, 2016, 17:49 Bruno Jouhier wrote: > try/catch is often

Re: A Result class for functions that may return errors

try/catch is often misunderstood as people think that they MUST catch errors as close as possible to the point where they may be thrown. Good EH practice is exactly the opposite: place a few try/catch in strategic places where you can report the error and recover from it; and let errors bubble

Re: Re: A Result class for functions that may return errors

I would also like to point out that V8 is one of few that don't optimize `try-catch`, and both Chakra and SpiderMonkey do optimize them IIRC (the latter has trouble optimizing functions that throw, though). On Tue, Oct 18, 2016, 15:29 Josh Tumath wrote: > > Not sure if

Re: Feature Request: Make ECMA262 a superset of JSON

Inline. On Tue, Oct 18, 2016, 12:01 Richard Gibson wrote: > On Tue, Oct 18, 2016 at 8:57 AM, Isiah Meadows > wrote: > > I'll point out that encoding and evaluating JSON literally can easily > become a potential security issue, anyways (consider

Re: Re: A Result class for functions that may return errors

> Not sure if I'm missing something, but wouldn't it be trivial to code that > constructor in JS? Yes it would be trivial, but my design I came up with was an example. The point I wanted to get across was to have some sort of standard practice for error handling using `return` rather than

Re: A Result class for functions that may return errors

Not sure if I'm missing something, but wouldn't it be trivial to code that constructor in JS? ```js class Result { constructor (type, value=true) { this[type] = value; } } function add(data) { if (data !== Object(data)) { return new Result('error', new Error('The data is not an

A Result class for functions that may return errors

At the moment, when we call a synchronous function that runs some kind of operation, there are two obvious ways of returning whether there has been an error: returning a boolean or throwing an error. Returning a boolean to show whether the operation worked is simple, but doesn't give any

Re: Power operator, why does -2**3 throws?

If tc39 wanted to implement it one way or the other, they would indeed use precedence. The problem is that the precedence of unary '-' vs binary '**' is ambiguous *between different people's heads* -- not just a little, but a lot. So whichever precedence you pick, some people will be very

Re: Feature Request: Make ECMA262 a superset of JSON

On Tue, Oct 18, 2016 at 8:57 AM, Isiah Meadows wrote: > I'll point out that encoding and evaluating JSON literally can easily > become a potential security issue, anyways (consider if a user can encode > `-->` in the relevant data). But you might have a point if you >

Feature Request: Make ECMA262 a superset of JSON

Note that `["__proto__"]` is different from `__proto__`, while `"__proto__"` is the same as `__proto__`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Feature Request: Make ECMA262 a superset of JSON

Okay. I stand corrected (it was in fact `["__proto__"]` that actually evaluates to the property). - Isiah Meadows m...@isiahmeadows.com On Tue, Oct 18, 2016 at 9:58 AM, Raul-Sebastian Mihăilă < raul.miha...@gmail.com> wrote: > Note that `["__proto__"]` is different from `__proto__`, while

Re: Power operator, why does -2**3 throws?

There are many other cases when with no parens involved, people have different expectations on the outcome. If expression looks ambigous the actual result always depends on operators precedence, it's how language worked for years, and I don't remember any big problems due to that. Jordan Harband

Re: Power operator, why does -2**3 throws?

It's quite simple (as has already been stated): some people expect `-x ** y` to be `-(x ** y)`. Some expect it to be `(-x) ** y`. The early SyntaxError ensures that nobody is confused - programmers will immediately add parens to disambiguate. Avoiding a potential footgun for the next 50 years,

Re: Power operator, why does -2**3 throws?

I must say throwing here, instead of relying on math dictated operators precedence looks really bad. It's very surprising to those well experienced with the language, and totally inconsistent with how operators worked so far (there is no previous case where one will throw for similar reason).