Re: Why does Object.keys return an Array instead of a Set?

Interesting, on my system I consistently see Set iteration is faster (I replayed it many times). I'm in Chrome 85, Linux. This might be temporary. > `new Set(Object.keys(obj))` That creates two objects and an iteration (will the engine optimize that away?), while `Object.keySet` (or similar)

Re: Why does Object.keys return an Array instead of a Set?

`new Set(Object.keys(obj))` seems pretty straightforward - I doubt it's worth adding something to the language just to make that shorter. Separately, if you're looking for a deduped O(1) lookup of key presence, you already have _an object_ - `Object.prototype.hasOwnProperty.call(obj, key)`. On

Re: Why does Object.keys return an Array instead of a Set?

Other than the fact that Object.keys existed really before Sets, you are comparing apples and oranges here in your benchmarks. the include method has to scan the array in order to find elements, but sets are objects which are just hash tables. Also you typically don't get the keys array to check

Re: Why does Object.keys return an Array instead of a Set?

ell that makes sense! Would it be worth adding an option like > `Object.keys(obj, true)` to return a set? Or perhaps > `Object.keySet(obj)`? > #!/JoePea > > On Fri, Oct 16, 2020 at 11:54 PM Jordan Harband wrote: > > > > Because Object.keys was standardized in 2009, 6 years befo

Re: Why does Object.keys return an Array instead of a Set?

Well that makes sense! Would it be worth adding an option like `Object.keys(obj, true)` to return a set? Or perhaps `Object.keySet(obj)`? #!/JoePea On Fri, Oct 16, 2020 at 11:54 PM Jordan Harband wrote: > > Because Object.keys was standardized in 2009, 6 years before Set existed. > >

Re: Why does Object.keys return an Array instead of a Set?

Because Object.keys was standardized in 2009, 6 years before Set existed. On Fri, Oct 16, 2020 at 6:51 PM #!/JoePea wrote: > Sets are faster, even for tiny lists of four items. See the perf tests > (tested in Chrome): > > https://twitter.com/trusktr/status/1315848017535098880 > >

Why does Object.keys return an Array instead of a Set?

Sets are faster, even for tiny lists of four items. See the perf tests (tested in Chrome): https://twitter.com/trusktr/status/1315848017535098880 https://twitter.com/trusktr/status/1317281652540731392 #!/JoePea ___ es-discuss mailing list

Slight return to BigInt. Was: JSON.parse should be simple and idiot-proof

On 2018-10-21 08:01, kai zhu wrote: wish to express skepticism for the stage-1 proposal "JSON.parse source text access" [1], from web-integration perspective. Be happy, now you have not less than TWO proposals for extending the ES6 JSON object! :-) A [potentially biased] comparison between

Re: await enhancement proposal: Wrap Array return values with Promise.all

ings, >>> >>> I have enjoyed using the `await` keyword tremendously in async code. One >>> point I notice in using it is that it is ideal in terms of clarity and >>> composability but limited in a sense to sequential composition. That is, I >>> cannot easily u

Re: await enhancement proposal: Wrap Array return values with Promise.all

t is, I >> cannot easily use `await` (by itself) to do parallel calculations. >> >> A few times, I have myself hit a bug where I return (without thinking) an >> Array of Promise only to find that none will resolve using `await` on the >> Array. I noticed others have similar bug

Re: await enhancement proposal: Wrap Array return values with Promise.all

I have myself hit a bug where I return (without thinking) an > Array of Promise only to find that none will resolve using `await` on the > Array. I noticed others have similar bugs. [1,2] I frequently wind up > wrapping them in one of two ways: a) occasionally a for loop that awaits >

await enhancement proposal: Wrap Array return values with Promise.all

. A few times, I have myself hit a bug where I return (without thinking) an Array of Promise only to find that none will resolve using `await` on the Array. I noticed others have similar bugs. [1,2] I frequently wind up wrapping them in one of two ways: a) occasionally a for loop that awaits each

Re: Trigger `catch`/`finally` with rejected `return` promise in `async` functions

> Le 9 sept. 2018 à 23:49, Isiah Meadows a écrit : > > Does `return foo` not seemingly imply the implicit unwrapping is > occuring *inside* the function? For me, no. If I want to await the resolution of the promise `foo` before handling the `catch` or the `finally` block, I e

Re: Trigger `catch`/`finally` with rejected `return` promise in `async` functions

Does `return foo` not seemingly imply the implicit unwrapping is occuring *inside* the function? > Note as well that `return await` introduces extra ticks, potentially slowing > down your code unnecessarily. I'm aware. BTW, it's not like the implicit `return` inside `try`/`catch`/`f

Re: Trigger `catch`/`finally` with rejected `return` promise in `async` functions

I think the explicit `await`, indicating you want to handle it in the `async function`, is a much better way to do it. Note as well that `return await` introduces extra ticks, potentially slowing down your code unnecessarily. On Sun, Sep 9, 2018 at 1:35 PM, Isiah Meadows wrote: > Yes, an

Re: Trigger `catch`/`finally` with rejected `return` promise in `async` functions

Yes, and I know it's a breaking change. And although ESLint does have a rule banning `return await` [1], they did have to fix it to account for the fact "fixing" the inconsistency breaks `try`/`catch`/`finally` [2]. I'm specifically proposing it to avoid the counterintuitiv

Re: Trigger `catch`/`finally` with rejected `return` promise in `async` functions

So are you saying that `return promise` and `return await promise` should have identical behavior in the context of an async function? Wouldn't that be a breaking change? And isn't it trivially solvable with a linter rule? On Sun, Sep 9, 2018, 13:29 Isiah Meadows wrote: > I know this requi

Trigger `catch`/`finally` with rejected `return` promise in `async` functions

I know this requires a bit of an exception, but I feel `catch`/`finally` should trigger when a promise `return`ed from an `async` function rejects. It just seems incredibly odd not to, since the usual intuition is that if an error occurs during the execution of a function, it's catchable

Re: return =

like the opposite of one. Pascal works that way too. You use an assignment statement to assign to the name of the function to set a function's return value. Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org

Re: return =

ften felt the need >> to indicate a return value other than as part of a `return` statement. >> >> Perhaps this is my BASIC background--the dialect I used all those years ago >> allowed an assignment to the function name to pre-specify a return value, >> which wou

Re: return =

Wow that's fanatically disgusting. Please no. On Mon, Sep 3, 2018, 12:27 Bob Myers wrote: > To continue the "stupid idea of the day" series, I have often felt the > need to indicate a return value other than as part of a `return` statement. > > Perhaps this is my BASIC bac

return =

To continue the "stupid idea of the day" series, I have often felt the need to indicate a return value other than as part of a `return` statement. Perhaps this is my BASIC background--the dialect I used all those years ago allowed an assignment to the function name to pre-specify a re

Re: proposal of function return with object destructor

it's pretty much the same thing, but an expression instead. Well damnit... On Tue, 10 Oct 2017 at 12:15 Новиков Денис <den-...@yandex.ru> wrote: > Hi! Sorry, I don't sure that it is a place for feature request - pls, > write if I wrong. > My proposal is to allow return of part of objec

Re: proposal of function return with object destructor

; My proposal is to allow return of part of object fields. > > Yesterday I wrote some ugly code: > > const { id, displayName, type, isEnabled } = segment; > return { id, displayName, type, isEnabled }; > > > There is problem with duplication. I think next variant looks

Fwd: proposal of function return with object destructor

Hi! Sorry, I don't sure that it is a place for feature request - pls, write if I wrong.My proposal is to allow return of part of object fields. Yesterday I wrote some ugly code:const { id, displayName, type, isEnabled } = segment;  return { id, displayName, type, isEnabled }; There is problem

Re: super return

On 08/29/2017 08:56 AM, Allen Wirfs-Brock wrote: On Aug 28, 2017, at 12:29 PM, Sebastian Malton <sebast...@malton.name <mailto:sebast...@malton.name>> wrote: The outcome of this basically means "return from current context up one level and then return from there”. This wo

Re: super return

-discuss@mozilla.orgSubject: Re: super return Perhaps if the nested function is lexically inside such super function it can be fair game and actually quite powerful and liberating.Unconstrained 'upleveling' is IIRC valid in such wonderful languages as Tcl. This unverified fact is presented without opinion

Re: super return

, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: > On Aug 28, 2017, at 12:29 PM, Sebastian Malton <sebast...@malton.name> > wrote: > > The outcome of this basically means "return from current context up one > level and then return from there”. > > > This wo

Re: super return

ion with a custom exit condition, e.g. ``` myArray .takeWhile( element=>{ let condition //calculate condition return condition } ) ``` Prior art: Java 9, rxjs, lodash and possibly others On Tue, 29 Aug 2017 at 21:27 Allen Wirfs-Bro

Re: super return

> On Aug 28, 2017, at 12:29 PM, Sebastian Malton <sebast...@malton.name> wrote: > > The outcome of this basically means "return from current context up one level > and then return from there”. This would be a terrible violation of functional encapsulation. How do

Re: super return

On 29 August 2017 at 14:30, Sebastian Malton <sebast...@malton.name> wrote: > If a function outlives its creation scope then this would do exactly what > a normal return would do. > That makes no sense, because that's a completely different continuation, usually expecting diffe

Re: super return

If a function outlives its creation scope then this would do exactly what a normal return would do

Re: super return

On 28 August 2017 at 21:29, Sebastian Malton <sebast...@malton.name> wrote: > Thus I propose the new syntax `super return` and any other positive number > of supers. This syntax is currently not valid in any scenario and with the > current meaning of super seems, to me at least,

Re: super return

s it > stops any further calls and then returns the first parameter past > > It's the outer function's responsibility to return appropriate values. > A map() call that didn't return an array would cause a lot of > problems; a forEach call that returned something meaningful would be >

Re: super return

> rectified by having it be a function that you call and when it calls it stops > any further calls and then returns the first parameter past It's the outer function's responsibility to return appropriate values. A map() call that didn't return an array would cause a lot of problems; a

Re: super return

if (arr.find(e => typeof e != 'number')) throw new Error('...'); return arr.map(e => { if (!...) throw new Error(...); return e * 2; }); Odds are you need a conditional block, might as well be try catch. -- Michael J. Ryan - track...@gmail.com - http://tracker1.info Please excuse g

Re: super return

it be a function that you call and when it calls it stops any further calls and then returns the first parameter past   Original Message   From: jackalm...@gmail.com Sent: August 28, 2017 4:17 PM To: sebast...@malton.name Cc: es-discuss@mozilla.org Subject: Re: super return On Mon, Aug 28, 2017 at 12

Re: super return

ak things since in some cases, > again forEach, the return value in explicitly defined. > > Thus I propose the new syntax `super return` and any other positive number > of supers. This syntax is currently not valid in any scenario and with the > current meaning of super seems, t

Re: super return

That is for returning values of arrays (or slightly changed values). I am more talking about for errors and suchExample:```jsfunction someThing(doWith) {    return doWith.map(elem => {        if (typeof elem !== "number") {            super return "Not all are numbers" ;

Re: super return

t; <sebast...@malton.name> wrote: > I have seen some people want to modify some of the array prototype > functions, especially forEach, so that returning from them returns a value. > However, I have also seems that this could break things since in some > cases, again forEach, the return

super return

I have seen some people want to modify some of the array prototype functions, especially forEach, so that returning from them returns a value. However, I have also seems that this could break things since in some cases, again forEach, the return value in explicitly defined. Thus I propose

Re: Return value of forEach

i had seen some people transform{  doSth();  return;}toreturn void doSth();for saving the `{}` and line breaks. So maybereturn arr.forEach(...)is just been written due to same reason

Re: Return value of forEach

Array.prototype.takeWhile` method for that (which returns a new >> array taking elements while the return value of the predicate is truthy). >> > > This is for when you don't want to create a new array, for either semantic > or memory pressure reasons. > > -- T.J. Crowder > For

Re: Return value of forEach

m obsessed with avoiding having multiple statements if they can get away with one, even with code that makes no semantic sense; I've seen this kind of return from methods many times: ```js if (someCondition) return somethingKnownNotToHaveAReturnValue(); ``` ...where `somethingKnownNotTo

Re: Return value of forEach

On Tue, Jul 25, 2017 at 5:06 AM, Naveen Chawla <naveen.c...@gmail.com> wrote: > I would not overload `each` with any early termination, I would probably > have an `Array.prototype.takeWhile` method for that (which returns a new > array taking elements while the return value o

Re: Return value of forEach

array taking elements while the return value of the predicate is truthy). On Tue, 25 Jul 2017 at 04:09 Tab Atkins Jr. <jackalm...@gmail.com> wrote: > On Mon, Jul 24, 2017 at 3:31 PM, T.J. Crowder > <tj.crow...@farsightsoftware.com> wrote: > > On Mon, Jul 24, 2017 at 9:58 PM,

Re: Return value of forEach

..that *do* and *do not* rely on the fact that promise resolves with > `undefined`. (The above does not.) > > Hopefully, ones that do are few and far between. But webscale is massive, > "few and far between" can be an unacceptably high number. > > If there were an appetite f

Re: Return value of forEach

ween. But webscale is massive, "few and far between" can be an unacceptably high number. If there were an appetite for `Array.prototype.each`, I'd like to address not just the return value but other issues with `Array.prototype.forEach` as well (like step value, per-iteration updates of the index,

Re: Return value of forEach

On Sun, Jul 23, 2017 at 6:53 AM, Naveen Chawla wrote: > Does anybody have any opinion on a new Array.prototype.each method that does > the same as forEach but returns the array, thereby allowing chaining with > sort, map, filter etc., while also preserving backwards

Re: Return value of forEach

not seeing it on github. > If you're thinking of `every` and `some`, they don't return a reference to > the array, which seemed to be important to Naveen for chaining. > > -- T.J. Crowder > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Return value of forEach

very` and `some`, they don't return a reference to the array, which seemed to be important to Naveen for chaining. -- T.J. Crowder ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Return value of forEach

ed over until the callback is called with >> a truthy value (falsey also ends) >> >> >> >> *From:* naveen.c...@gmail.com >> *Sent:* July 6, 2017 8:44 AM >> *To:* es-discuss@mozilla.org >> *Subject:* Re: Re: Return value of forEach >> >> In that

Re: Return value of forEach

g iterated over until the callback is called with > a truthy value (falsey also ends) > > > > *From:* naveen.c...@gmail.com > *Sent:* July 6, 2017 8:44 AM > *To:* es-discuss@mozilla.org > *Subject:* Re: Re: Return value of forEach > > In that case, there should be a new

Re: Return value of forEach

)From: naveen.c...@gmail.comSent: July 6, 2017 8:44 AMTo: es-discuss@mozilla.orgSubject: Re: Re: Return value of forEach In that case, there should be a new function:"forEvery" (or "forEachAndR

Re: Re: Return value of forEach

In that case, there should be a new function: "forEvery" (or "forEachAndReturn" or "each" or whatever) that does exactly the same as "forEach" but returns the array. This is a much needed feature for those of us that don't want to create a new array on each invocation but still have the ability

Re: Letting RegExp method return something iterable?

@Oriol Thanks for your reply! On 2017/06/18 21:33, Oriol _ wrote: There is a `String#matchAll` proposal in stage 1. https://github.com/tc39/String.prototype.matchAll https://github.com/tc39/String.prototype.matchAll> Oriol ___ es-discuss mailing

Re: Re: Letting RegExp method return something iterable?

There is a `String#matchAll` proposal in stage 1. https://github.com/tc39/String.prototype.matchAll Oriol ___ es-discuss mailing list es-discuss@mozilla.org

Re: Re: Letting RegExp method return something iterable?

Although It seems that some people agreed with appending `RegExp#execAll` to EcmaScript 4 years ago, what happened to it after that? topic: https://esdiscuss.org/topic/letting-regexp-method-return-something-iterable implementation: https://www.npmjs.com/package/regexp.execall

Re: Class method shorthand return

's suggestion here. This is in significant use in the React community already, via transpiling, e.g. this works: ```js class Widget extends React.Component { handleClick = _ => { this.setState(state => ({counter: state.counter + 1})); }; render() { re

Re: Class method shorthand return

to be defined class MyClass { deleteProfileImage : () -> (...) //or some other new shorthand for regular functions isMyClass : true static myStaticMethod : () =>(...) } instead of class MyClass { deleteProfileImage(){ return ... } } MyClass.prototype.isMyClass

Class method shorthand return

Hi, I this return shorthand would be helpful. class MyClass { deleteProfileImage() => () } as we already have this const myFunction = () => (); any thoughts? Serghei ___ es-discuss mailing list es-discuss@mozilla.org

Re: Enable async/await to work on functions that don't just return promises.

Actually, this proposal would be a revolution and I can think of too many edge cases to make it viable. Consider: async function foo() { async function bar() { [1,2,3].forEach(async function() { async return 3; }); } return (await bar()) + 39; } What

Re: Enable async/await to work on functions that don't just return promises.

have existed in Node-land for quite a while, and can automatically convert functions that take Node-style callbacks into functions that return promises. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Enable async/await to work on functions that don't just return promises.

nction itself should surely > be synchronous. Shouldn't functions that may not have `await` in them, but > instead that are actually asynchronous and hence use the `async return` > keyword be the ones we define with `async`? > > > In the Javascript (and Midori) model, concurrent exec

Re: Enable async/await to work on functions that don't just return promises.

nous. Shouldn't functions that may not have `await` in them, but > instead that are actually asynchronous and hence use the `async return` > keyword be the ones we define with `async`? > > > In the Javascript (and Midori) model, concurrent execution of multiple > activ

Re: Enable async/await to work on functions that don't just return promises.

be asynchronous here? To my mind, no, it shouldn't. > Every single line here is synchronous, so the function itself should surely > be synchronous. Shouldn't functions that may not have `await` in them, but > instead that are actually asynchronous and hence use the `async return` > ke

Re: Enable async/await to work on functions that don't just return promises.

use the `async return` > keyword be the ones we define with `async`? In the Javascript (and Midori) model, concurrent execution of multiple activities is achieved by breaking those activities up into coarse-grained, application-defined "turns" (or "jobs") and interleav

Re: Enable async/await to work on functions that don't just return promises.

A very interesting read indeed Alexander!  Gave me a new example to give when people ask what the worst code I'd ever seen was: Promise DoSomething(Promise cmd) { return cmd.WhenResolved( s => { if (s == "...") { return DoSomethingElse(...).WhenResolved( v => { return ...;

Re: Enable async/await to work on functions that don't just return promises.

Required reading for anyone who wants to be so... opinionated ;) http://joeduffyblog.com/2015/11/19/asynchronous-everything/ On Sun, 26 Feb 2017 at 16:35, Florian Bösch wrote: > On Sun, Feb 26, 2017 at 5:30 PM, Codefined > wrote: > > I'll be

Re: Enable async/await to work on functions that don't just return promises.

You seem to be feel incredibly jaded about nearly everything posted here.   Perhaps if you suggested your own proposal that showed the clear advantages of co-routines as you see it, then you might solve some of the issues instead of just whining about it. I assume that every single Javascript

Re: Enable async/await to work on functions that don't just return promises.

On Sun, Feb 26, 2017 at 5:30 PM, Codefined wrote: > I'll be interested to see what you guys consider the > advantages/disadvantages of this method, which I hope to be "the middle > between two ends" on whether to go fully into promises or fully into > co-routines.

Re: Enable async/await to work on functions that don't just return promises.

of `async` prepended before it.  Also, unlike the `return` statement in a synchronous function, the asynchronous code has `async return`.  Examples: function someSync() { return "Sync"; } async function someAsync() { setTimeout(() => { async return "Async"; }, 1000);

Re: Enable async/await to work on functions that don't just return promises.

await/async are de-facto co-routines. await/async will infect all code by necessity of software engineering. At which point they're actual co-routines, implemented badly, without a proper API. On Sun, Feb 26, 2017 at 3:26 PM, Jerald Cohen wrote: > Florian, > > You sure

Re: Enable async/await to work on functions that don't just return promises.

Florian, You sure you're not just adding more complexities to a language with features that were _meant_ to remove such complexity? Codefined's solution to me seems to be the one with the least amount of added techniques in order to learn. Although I understand how co-rountines are awesome,

Re: Enable async/await to work on functions that don't just return promises.

On Sun, Feb 26, 2017 at 2:51 PM, Codefined wrote: > What I feel we need is some way of making an asynchronous function > "appear" to be synchronous. > That's what co-routines are. Best practices for co-routines is usually to have some sort of API to spawn them (like

Re: Enable async/await to work on functions that don't just return promises.

Ah, that would indeed make sense.  What I feel we need is some way of making an asynchronous function "appear" to be synchronous.  Actually that's sort of what I expected async/await to do, but that only seems to affect where it's called, as opposed to the function

Re: Enable async/await to work on functions that don't just return promises.

On Sun, Feb 26, 2017 at 2:17 PM, Codefined wrote: > Because `d()` is no longer an asynchronous function, you can call it like > normal, surely? > Only async functions can await. Only await pauses execution to wait on async.

Re: Enable async/await to work on functions that don't just return promises.

Hey Florian, Why do we even need to do that? async function someAsync() { something(() => { return "hello"; }); } let d = function() { return await someAsync(); } let c = function() { return d(); } Because `d()` is no longer an asynchronous function, you can call it like normal, su

Re: Enable async/await to work on functions that don't just return promises.

On Sun, Feb 26, 2017 at 2:08 PM, Jerald Cohen <cohenjera...@gmail.com> wrote: > (although, at the moment, I fail to see why one can't just use a normal > "return"). > You're probably unaware of this, but there is a fixation in this community, and many adjacent ones, th

Re: Enable async/await to work on functions that don't just return promises.

lly devolves into implicit coroutines, so > any argument would be moot. > > To illustrate, suppose you have these 4 functions: > > let a = function(){ > return b(); > } > > let b = function(){ > return c(); > } > > let c = function(){ >return d(); &g

Re: Enable async/await to work on functions that don't just return promises.

async Task LongRunningOperationAsync() // assume we return an int from this long running operation { await Task.Delay(1000); //1 seconds delay return 1;} Taken from this stackoverflow question <http://stackoverflow.com/questions/14455293/how-and-when-to-use-async-and-await>. I wou

Re: Enable async/await to work on functions that don't just return promises.

It would be nice if there even was an argument, but there isn't. There isn't because async/await naturally devolves into implicit coroutines, so any argument would be moot. To illustrate, suppose you have these 4 functions: let a = function(){ return b(); } let b = function(){ return c

Re: Enable async/await to work on functions that don't just return promises.

d to any kind of standard. > > async function asyncFunction() {let [err, data] = await asyncFunction() > } > > function asyncFunction(){ > return otherAsyncFunction(); > } > > Even simpler, you'd just need co-routines. >

Re: Enable async/await to work on functions that don't just return promises.

into a situation like this in your first program (for example, reading/writing to a file using promises).  Take: function asyncFunction() { return new Promise(resolve => { someAsync('data', (...args) => resolve(args)) }) } Here you have to explain the concept of returning a promise, anonymous functions,

Re: Enable async/await to work on functions that don't just return promises.

Here's my thoughts: 1. There's minimal benefit to be gained with your example, since it can already be simulated very similarly with the current API: function asyncFunction() { return new Promise(resolve => { someAsync('data', (...args) => resolve(args)) }) } 2. This

Re: Enable async/await to work on functions that don't just return promises.

e. Should never have been added to any kind of standard. > > async function asyncFunction() {let [err, data] = await asyncFunction() > } > > function asyncFunction(){ return otherAsyncFunction(); } Even simpler, you'd just need co-routines.

Enable async/await to work on functions that don't just return promises.

promises in the first place.  Wouldn't it be so much more powerful to be able to use completely normal syntax, as you would in synchronous code as well as the option of promise chains? For example, take the following code snippet: async function asyncFunction() { return new Promise((resolve, reject

Re: A Result class for functions that may return errors

Inline On Tue, Oct 18, 2016, 18:23 Josh Tumbath <j...@joshtumath.uk> wrote: > The issue with that, though, is returning `undefined` is really no > different to returning `null` in a sense. Null is considered bad because > errors can crop up from not handling null as a re

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

return a value 3. They can throw an error With these three things in mind how should we actually consume these things called iterators. The current methods are (in addition to the await versions in async-iteration): 1. The for-of loop but it can only use non-completion values 2

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 <bjouh...@gmail.com> wrote: > try/catch

Re: A Result class for functions that may return errors

it comes to releasing resources and restoring program invariants. I don't see a need for a special Return class. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

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

gt; 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

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` rathe

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

A Result class for functions that may return errors

either the correct result or information about the error. This is a simple way to return error results without the overheads of throwing Errors. Rust has two enums for this purpose: `Option` and `Result` (https://doc.rust-lang.org/book/error-handling.html#the-option-type). The additional benefit

Re: Should RegExp(regexp, flags) always return a functional RegExp for reasonable values of flags?

Thinking more about it: there is a fatal incompatibility: ```js /^\u{12345}$/u.test("\u{12345}") // true /^\u{12345}$/.test("u".repeat(12345)) // true (annex b) ``` and ```js /^\u{1F4A9}$/u.test("\u{1F4A9}") // true /^\u{1F4A9}$/.test("u{1F4A9}") // true (annex b) ``` —Claude > Le 19 mai 2016

Re: Should RegExp(regexp, flags) always return a functional RegExp for reasonable values of flags?

Ah - in that case, no, I would not necessarily expect that the source of a u-mode regex would produce a valid regex in another context without the "u" flag. On Thu, May 19, 2016 at 10:18 AM, Claude Pache wrote: > > > Le 19 mai 2016 à 17:54, Jordan Harband

Re: Should RegExp(regexp, flags) always return a functional RegExp for reasonable values of flags?

> Le 19 mai 2016 à 17:54, Jordan Harband a écrit : > > I'm not as sure about `eval`, but absolutely `new RegExp(rx.source, > rx.flags)` should always imo reproduce a functionally equivalent regex. Sure, but it doesn’t answer the question. I am concerned with, e.g., `new

Re: Should RegExp(regexp, flags) always return a functional RegExp for reasonable values of flags?

contains legal RegExp > flag characters, should ideally the following expressions > > ```js > RegExp(rx, f) > eval("/" + rx.source + "/" + f) > ``` > > always return a functional regexp? > > Practical example: `rx = /\-/`, and `f === "u"` (reca

Should RegExp(regexp, flags) always return a functional RegExp for reasonable values of flags?

Hi, Given a RegExp object `rx` and a string `f` that contains legal RegExp flag characters, should ideally the following expressions ```js RegExp(rx, f) eval("/" + rx.source + "/" + f) ``` always return a functional regexp? Practical example: `rx = /\-/`, and

  1   2   3   4   5   >