Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

There's a tradeoff here. If it's an extension of `for...of`, it's much clearer for users. If it's a method of `Promise`, it's much more extensible. Perhaps it could be a little bit of both? Maybe something like: ``` for(item of items : Scheduler.limit(5)) { // ... } ``` where

Re: A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

Out of curiosity, what is the expected benefit wrt Esprima, Babel or Shift? In particular since there is no standard AST for ECMAScript yet [1]? Cheers, David [1] Ok, that's a subset of https://github.com/tc39/proposal-binary-ast, which is in the pipes. On 14/09/2019 07:46, Jack Works wrote: >

A new proposal for syntax-checking and sandbox: ECMAScript Parser proposal

Just like DOMParser in HTML and Houdini's parser API in CSS , a built-in parser for ECMAScript itself is quite useful in many ways. Check out https://github.com/Jack-Works/proposal-ecmascript-parser for

Re: Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

> Also, wouldn't this be better formulated in terms of tasks and not promises? Tasks could be decoupled from list iteration, for one. That's interesting, what would this look like? -- Chief Software Architect Apostrophe Technologies Pronouns: he / him / his

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

Also, wouldn't this be better formulated in terms of tasks and not promises? Tasks could be decoupled from list iteration, for one. On Sat, Sep 7, 2019 at 14:28 Cyril Auburtin wrote: > It should really be in the form of a static method like `Promise.map` or > some other naming > > On Sat, Sep

Re: Use hashes as keys instead of toString() for values like object, function to index objects

On 9/8/19 1:24 PM, Michael Luder-Rosefield wrote: I'd suggest that the best way of doing this, without breaking existing code, is to put some sugar around Maps so that they can be used in a more Object-y way. For starters, Map literal declarations and assignment could benefit from this. +1

Re: Optional chaining syntax but with the "mice" operator ?

Yes, we can all use N variables in the middle of a chain, but `any.thing().that.queries().rows` is a more common/natural pattern. Like in everything in JS, developers need to know what they are doing. Every operator can create bugs (i.e. NaN results or bad string concatenations instead of sums)

Re: Optional chaining syntax but with the "mice" operator ?

I wasn't comparing it to your `??` variant of the same cases, which has the same issues - but only because that is a curious way of using `??` in the first place. Ordinarily `??` would be used to resolve to a value *of the same type* to allow clear unambiguous data flow through the variables.

Re: Optional chaining syntax but with the "mice" operator ?

I guess we have a different opinion about what's confusing and what's not. To me having a `??` with potential side-effects is more bug prone than the proposed mouse trap, as it's subtle, yet "promoted" by the `?.` + `??` pattern. On Mon, Sep 9, 2019 at 11:16 AM Naveen Chawla wrote: >

Re: Optional chaining syntax but with the "mice" operator ?

"resultsContainerOrSingleResult" appears to be the end variable. I just find this "shoehorning" to be a sacrifice in code clarity and manageability. "rowCount" would be undefined if greater than 0 in the 2nd example, it seems. Surely that is a confusing behaviour, if not bug prone On Mon, 9 Sep

Re: Use hashes as keys instead of toString() for values like object, function to index objects

Why not both? My point is that Map/WeakMap do a lot of what people historically use Object for, but in a better way; certainly, they solve Tadas's issue here. The trouble is that Objects have a lot of convenient sugar around them that make them easier, and more pleasant, to use. We really

Re: Optional chaining syntax but with the "mice" operator ?

so *maybe* we'll come back... On Mon, Sep 9, 2019 at 10:04 AM Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > `require("module") initially explained. > > `db.get(SQL) that won't fail but might not return the desired result, so that you end up > holding the top most object with all the

Re: Optional chaining syntax but with the "mice" operator ?

`require("module") wrote: > There has to be a better pattern than returning the "foo()" if the baz > property doesn't exist. > > I'm curious what you would want to do with the resulting "foo()" anyway. I > can imagine a flow where I want "bar", and it doesn't exist it doesn't. I > cannot imagine

Re: Symbols and SymbolAt

see https://github.com/tc39/proposal-intl-segmenter 2019年9月9日 1:25 +0900、Dimitrian Nine のメール: > Thanks i found same ideas here: > > https://esdiscuss.org/topic/string-prototype-symbolat-improved-string-prototype-charat > https://esdiscuss.org/topic/working-with-grapheme-clusters > > But topics

Re: Use hashes as keys instead of toString() for values like object, function to index objects

On Sun, Sep 8, 2019 at 1:24 PM Michael Luder-Rosefield < rosyatran...@gmail.com> wrote: > I'd suggest that the best way of doing this, without breaking existing > code, is to put some sugar around Maps so that they can be used in a more > Object-y way. For starters, Map literal declarations and

Re: Use hashes as keys instead of toString() for values like object, function to index objects

I'd suggest that the best way of doing this, without breaking existing code, is to put some sugar around Maps so that they can be used in a more Object-y way. For starters, Map literal declarations and assignment could benefit from this. Suggestions for syntax welcome! On Sun, 8 Sep 2019, 12:36

Re: Symbols and SymbolAt

Thanks i found same ideas here: https://esdiscuss.org/topic/string-prototype-symbolat-improved-string-prototype-charat https://esdiscuss.org/topic/working-with-grapheme-clusters But topics was created - 6 years ago... And no news for working on it? ___

Re: Use hashes as keys instead of toString() for values like object, function to index objects

By default, the behavior would have to remain the same, or else it would break the web. See https://esdiscuss.org/topic/object-id-hash-etc for more on hash codes. On Sun, Sep 8, 2019 at 4:36 AM Tadas Lapė wrote: > The problem > > Javascript allows to index objects not only with strings,

Re: Symbols and SymbolAt

There's already `.codePointAt`, and `[...str].length`. The thing that's really needed more than code points is grapheme clusters; see https://esdiscuss.org/topic/working-with-grapheme-clusters On Sun, Sep 8, 2019 at 5:01 AM Dimitrian Nine wrote: > Maybe i don't know something, but want to

Re: Use hashes as keys instead of toString() for values like object, function to index objects

I wish for "development mode" in browsers, with runtime warning of such code constructs, but that would break backward compatibility. On Sun, 8 Sep 2019, 13:36 Tadas Lapė, wrote: > The problem > > Javascript allows to index objects not only with strings, numbers, but > also with objects. It

Re: Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

> Suppose you wanted to build an ordered array of results given the async processes. Suppose the iterations vary in duration. Without the "concurrent" keyword, the ordering is guaranteed. That's a really good point. And I did after all reference Promise.map from bluebird in my own discussion. I

Symbols and SymbolAt

Maybe i don't know something, but want to proposal idea: We have emojis and other symbols, that have many codepoints And 'emoji'.length > 1 My idea that we have something like 'emoji'.symbols - and get array of symbols, where symbol is array of codepoints And maybe method SymbolAt

Use hashes as keys instead of toString() for values like object, function to index objects

The problem Javascript allows to index objects not only with strings, numbers, but also with objects. It uses toString() object method to calculate the object index. If method is not overwritten, the generated index is "[object Object]". Many users do not know this or forget this and cause

Re: Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

Suppose you wanted to build an ordered array of results given the async processes. Suppose the iterations vary in duration. Without the "concurrent" keyword, the ordering is guaranteed. Suppose someone adds "concurrent" just motivated by performance. All of a sudden the ordering is messed up as

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

It should really be in the form of a static method like `Promise.map` or some other naming On Sat, Sep 7, 2019 at 6:40 PM Tom Boutell wrote: > Up to five instances of the loop body would be in progress, assuming at > least one of them awaits at some point. any await inside the loop body >

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

Up to five instances of the loop body would be in progress, assuming at least one of them awaits at some point. any await inside the loop body would be respected with regard to code that follows it in the loop body. The only place concurrency comes into play is that more than one of these

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

I don't understand how this would work. ``` for (const thing of things concurrency 5) { const result = await thing(); console.log(result); // <== what is `result` here, if the call to thing() hasn't completed? } ``` Also, it's intellectually unsatisfying that I can't specify concurrency for

Re: [Proposal] Refer to actual value : keyword "itself"

Can you currently do this with the "super" keyword outside of classes? On Fri, Sep 6, 2019 at 9:16 PM Jordan Harband wrote: > `var itself = 3;` means that your choice of keyword wouldn't be an option; > you'd be limited to something that was currently a syntax error. > > On Fri, Sep 6, 2019 at

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

*REVISED PROPOSAL (thanks for the input so far!)* *Background* Developers learning async programming in the modern async/await era frequently discover this useful pattern: ```js for (item of items) { await db.insert(item); // additional awaited operations, etc. } ``` This pattern extends

Re: Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

Omitting the "await" would not suffice for the original use case of "await": you need to know it actually completed before you continue to the code *after* the "for" loop. It would also unleash unbounded concurrency which usually doesn't end well. It takes us back to: "Sometimes my code works,

Re: Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

In my mind there is a cognitive load cost in adding language constructs (unless they significantly otherwise reduce cognitive load). In this case, I find omitting the "await" would suffice for a lot of people, and for those who want the loop to conceptually "hang" until all are completed (which I

Re: Optional chaining syntax but with the "mice" operator ?

There has to be a better pattern than returning the "foo()" if the baz property doesn't exist. I'm curious what you would want to do with the resulting "foo()" anyway. I can imagine a flow where I want "bar", and it doesn't exist it doesn't. I cannot imagine wanting the "foo()" in place of it.

Re: Optional chaining syntax but with the "mice" operator ?

Interesting I forgot about that, but it wouldn't cover the "trap here" use case. foo().bar ?! what => what : what; I'd like to forward foo() here On Sat, Sep 7, 2019, 11:45 Michael Luder-Rosefield wrote: > This is getting very reminiscent of my 'forwarding ternary' operator (or > whatever I

Re: Optional chaining syntax but with the "mice" operator ?

This is getting very reminiscent of my 'forwarding ternary' operator (or whatever I called it) I suggested a couple of years ago. I believe you were involved in the discussion, Andrea...! ``` const val = foo() ?! (x) => x.bar.baz : someFallbackValue; ``` On Sat, 7 Sep 2019, 10:17 Andrea

Re: Optional chaining syntax but with the "mice" operator ?

To better answer, let's start dropping any direct access and put a payload in the mix. As example, in the `foo()?.bar.baz` case, you might end up having `null` or `undefined`, as result, because `foo().bar` existed, but `bar.baz` didn't. In the `foo()?.bar?.baz` case, you might end up having

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

> With the promise.all, would each item in the iterable be an async function (or function returning a promise)? I mean, I'm presuming the point is to not have every item execute at the same time. Ah, correct, like in my [example](

Re: Optional chaining syntax but with the "mice" operator ?

On Fri, Sep 6, 2019 at 8:04 AM Andrea Giammarchi wrote: > Indeed I'm not super convinced myself about the "branching issue" 'cause > `const result = this?.is?.branching?.already` and all I am proposing is to > hint the syntax where to stop in case something else fails down the line, as > in

Re: Optional chaining syntax but with the "mice" operator ?

It's On Fri, Sep 6, 2019, 20:14 Jordan Harband wrote: > Syntactically marking, in a chain, what you'd like the final value of the > chain to be, seems interesting - forcing optionality into it seems > unnecessary, though, if such a syntactic marker could be attached to all > forms of property

Re: Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

> Can someone tell me exactly how just omitting "await" doesn't broadly achieve the "concurrency" objective? Omitting "await" gives us no assurance that all of the iterations completed prior to exit from the "for...of" loop. My proposal should have specified that regardless of whether

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

Can someone tell me exactly how just omitting "await" doesn't broadly achieve the "concurrency" objective? On Fri, 6 Sep 2019, 20:04 Cyril Auburtin, wrote: > It could be probably added as a `Promise.all(iterable, concurrency?)` > > Some existing implementations: > -

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

With the promise.all, would each item in the iterable be an async function (or function returning a promise)? I mean, I'm presuming the point is to not have every item execute at the same time. -- Michael J. Ryan Website: https://www.tracker1.info/ Email: track...@gmail.com Mobile:

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

It could be probably added as a `Promise.all(iterable, concurrency?)` Some existing implementations: - http://bluebirdjs.com/docs/api/promise.map.html - https://caolan.github.io/async/v3/docs.html#mapLimit - I tried to write one:

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

I am more interested in syntax two than syntax one, which I felt should probably be included for completeness. But hey, as you say, maybe not since unguarded concurrency is indeed usually a mistake. Taken on its own, do you have an objection to `for (item of items concurrency 5) { ... }`? On

Re: [Proposal] Refer to actual value : keyword "itself"

`var itself = 3;` means that your choice of keyword wouldn't be an option; you'd be limited to something that was currently a syntax error. On Fri, Sep 6, 2019 at 2:53 AM Cyril Auburtin wrote: > also optional-chaining will help > ```js > return { > ...state, > child: { >

Re: Optional chaining syntax but with the "mice" operator ?

Syntactically marking, in a chain, what you'd like the final value of the chain to be, seems interesting - forcing optionality into it seems unnecessary, though, if such a syntactic marker could be attached to all forms of property access. Something like: `a.b>.c.d` or `a?.b>?.c?.d` or

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

The current way to write what you want is: await Promise.all(itemsCursor.map(item => db.insert(item)); or await Promise.all(itemsCursor.map(Promise.guard(5, item => db.insert(item; if you are using a library like `prfun` (

Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

*Specifying concurrency for "for...of" loops potentially containing "await" statements in the loop body* In the async/await era, I see most developers using the async and await keywords in 90% of situations, shifting to "Promise.all" or the bluebird library only to cope with concurrency issues.

Re: Optional chaining syntax but with the "mice" operator ?

Indeed I'm not super convinced myself about the "branching issue" 'cause `const result = this?.is?.branching?.already` and all I am proposing is to hint the syntax where to stop in case something else fails down the line, as in `const result = this.?.is wrote: > Typically, "dot" expressions

Re: Optional chaining syntax but with the "mice" operator ?

Typically, "dot" expressions navigate through values of different types, making "type branching" the inevitable next step in those cases (unless you introduce a common method for further processing for each of those types). So I'm not sure how ultimately that would be avoided. On Fri, 6 Sep 2019

Re: Optional chaining syntax but with the "mice" operator ?

> Le 6 sept. 2019 à 14:35, Felipe Nascimento de Moura > a écrit : > > Doesn't that bring risks to breaking the web? > > You seen, many, MANY servers running php have the "shot-tags" feature > enabled, in which pages with will be interpreted. > In this case, any html page with embedded

Re: Optional chaining syntax but with the "mice" operator ?

You keep diverging from the intent, basing your answers on my quick'n'dirty examples. I agree my examples are probably not the best looking, but there are no solutions right now to retrieve one part of th echain that failed, if not repeating the chain, and eventually thesame errors, on the right

Re: Optional chaining syntax but with the "mice" operator ?

I'm not in TC39, sorry if I sounded like I was, just voicing my opinion. I think the example you gave is better served by throwing the exception from inside "query", instead of doing a "typeof" with the proposed operator afterward. I find "type branching" normally to be a cumbersome logical

Re: Optional chaining syntax but with the "mice" operator ?

Doesn't that bring risks to breaking the web? You seen, many, MANY servers running php have the "shot-tags" feature enabled, in which pages with will be interpreted. In this case, any html page with embedded scripts using this operator, or event .js files when the server is configured to also

Re: [Proposal] Refer to actual value : keyword "itself"

also optional-chaining will help ```js return { ...state, child: { ...state?.child, subchild: { ...state?.child?.subchild, property: (state?.child?.subchild?.property ?? 0) + 1 } } } ``` @Herby yes that's interesting, works in any order

Re: [Proposal] Refer to actual value : keyword "itself"

On 6. 9. 2019 10:34, Cyril Auburtin wrote: You could currently do ```js object.child.property /= 5 ``` with destructuring: ```js const {child: {subchild}, child} = state; Wow, I didn't know I can do that. Nice. ___ es-discuss mailing list

Re: [Proposal] Refer to actual value : keyword "itself"

Yes of course I could use the /= operator in this simple example, but not in more complex operations. About itself in a property, it's correct : I mean itself to refer to the actual value, the value being from a variable or an object property doesn't matter. itself would not be a this equivalent,

Re: [Proposal] Refer to actual value : keyword "itself"

Oops I forgot do-expression don't use `return`, so something, a bit ugly, like: ```js return { ...state, child: do { const {child} = state; ({ ...child, subchild: do { const {subchild} = child; ({ ...subchild, property: subchild.property

Re: [Proposal] Refer to actual value : keyword "itself"

You could currently do ```js object.child.property /= 5 ``` with destructuring: ```js const {child: {subchild}, child} = state; return { ...state, child: { ...child, subchild: { ...subchild, property: subchild.property + 1 } } } ``` or do-expressions: ```js return

Re: Optional chaining syntax but with the "mice" operator ?

The purpose is to address what chaining lacks, in terms of "stopping" at some point whenever it's available or not. Take this example: ```js // the current chaining operator const result = nmsp.some.payload()?.result ?? nmsp.some.payload(); // the mouse operator const result =

[Proposal] Refer to actual value : keyword "itself"

When we need to change a value using the old value : variable = itself + 5 // instead of variable = variable + 5 object.child.property = itself / 5 // instead of object.child.property = object.child.property / 5 Changing a value in nested objects is a pain, like Redux states for eg. return {

Re: Optional chaining syntax but with the "mice" operator ?

I think introducing this operator encourages bad logic design like "instanceof", isArray etc. These are unreadable disambiguation factors in that they don't inform about which part the expression is going to the next stage in the process. Also it leads to "type branching", which tends towards more

Re: Optional chaining syntax but with the "mice" operator ?

> Le 5 sept. 2019 à 23:39, Andrea Giammarchi a > écrit : > > This is basically a solution to a common problem we have these days, where > modules published in the wild might have a `default` property, to support ESM > logic, or not. > > ```js > // current optional chaining logic > const

Re: Optional chaining syntax but with the "mice" operator ?

As someone noticed already, the operator should be called eventually "mouse" operator, as mice is plural and was a misunderstand of mine  On Fri, Sep 6, 2019, 00:54 Andrea Giammarchi wrote: > Since somebody asked me already elsewhere about the expected precedence of > the operator, this would

Re: Optional chaining syntax but with the "mice" operator ?

Since somebody asked me already elsewhere about the expected precedence of the operator, this would be my answer: ```js const result = await dbQuery(data) wrote: > absolutely, I'm working with PostgreSQL these days and indeed for any > promise/awaited result this pattern looks like a win, and

Re: Optional chaining syntax but with the "mice" operator ?

absolutely, I'm working with PostgreSQL these days and indeed for any promise/awaited result this pattern looks like a win, and while it's targeting a limitation of the chaining one, it can be used in various other cases where knowing the initial result is more important than just falling back to

Re: Optional chaining syntax but with the "mice" operator ?

Another pattern it could be useful in is with, say, nosql dbs where something might be an object or id reference: ``` const fooId = foo wrote: > Another use case that I believe will be common is the following one: > > ```js > // current state of the art > const result = dbQuery(data)?.rows ??

Re: Optional chaining syntax but with the "mice" operator ?

Another use case that I believe will be common is the following one: ```js // current state of the art const result = dbQuery(data)?.rows ?? 'did it just failed or what?'; // VS the "mice operator" const result = dbQuery(data) wrote: > On Thu, Sep 5, 2019 at 2:39 PM Andrea Giammarchi > wrote:

Re: Optional chaining syntax but with the "mice" operator ?

On Thu, Sep 5, 2019 at 2:39 PM Andrea Giammarchi wrote: > > This is basically a solution to a common problem we have these days, where > modules published in the wild might have a `default` property, to support ESM > logic, or not. > > ```js > // current optional chaining logic > const imported

Optional chaining syntax but with the "mice" operator ?

This is basically a solution to a common problem we have these days, where modules published in the wild might have a `default` property, to support ESM logic, or not. ```js // current optional chaining logic const imported = exported?.default ?? exported; // my "mice operator" proposal const

Re: persisting large wasm-sqlite3 datasets in browser (beyond kv-storage)

Not sure this pertains to the ECMAScript spec in any way. You may have better luck with WICG, because they are who deal with those specs - those are specific to the web, while JS is used in places where those might not even make sense (like IoT sensors). - Isiah Meadows

persisting large wasm-sqlite3 datasets in browser (beyond kv-storage)

at work, we have browser-app that load-and-persist ~100MB (500k rows) csv-files into wasm-sqlite3 [1], (ingestion-time is ~15s for 100MB csv). we wish to go bigger, but chrome's indexeddb has a hard-limit of 125MB per key-value object (on windows). i don't have anything actionable. just want

Re: Moving forward with function decorators

Class member decorators are there: https://github.com/tc39/proposal-decorators Object method decorators: of course they do make sense but honesty I don't know do they need to be also included as a part of "function decorators proposal"? They look and behave very similar to class members. In other

Re: Moving forward with function decorators

I don't see any mention of class/object shorthand methods; would these be trivial, do you think? ``` class FooClass { @dec1 @dec2 bar () { } } const fooObj = { @dec1 @dec2 bar () { } } ``` -- Dammit babies, you've got to be kind. On Wed, 4 Sep 2019 at 11:49,

Fwd: Moving forward with function decorators

Here I described my thoughts about this topic https://github.com/finom/function-decorators-proposal. The main idea of moving forward with function decorators is to make them behave like there were defined and wrapped by another function, not more, and get rid of any hoisting when they're used.

RE: globalThis.assertOrThrow

https://esdiscuss.org/topic/native-assertions From: es-discuss On Behalf Of kai zhu Sent: Saturday, August 31, 2019 2:22 PM To: es-discuss Subject: globalThis.assertOrThrow having a universal assert function (similar to nodejs' assert builtin) might be useful. it could be name

globalThis.assertOrThrow

having a universal assert function (similar to nodejs' assert builtin) might be useful. it could be name "assertOrThrow" for web-compat. this would simplify writing common-case "throwaway" error-handling behavior in both browsers and nodejs: ```js // naive polyfill globalThis.assertOrThrow =

Re: Re: Async Class

Claude Pache > class consists not only of its constructor How i see it - seems all think that my idea not bad, but we have semantic hell. My thougth was Class is wrapper for constructor object And Async Class is same wrapper for constructor Promise of object kai zhu >class-factories are good

Re: Async Class

class-factories are good enough. as real-world example, google-puppeteer uses class-factories to promisify its constructors, which are easy-to-reason. if the below Browser/Page classes were also "async", it would be difficult to debug their intent in real-world code -- are their instances

Re: Async Class

> Le 26 août 2019 à 17:11, Dimitrian Nine a écrit : > > Class is just function constructor that return object Although in JS a class is represented by the same object as its constructor, I don’t think it is good to assimilate the concept of JS class and JS constructor. Indeed, a class

Re: Re: Async Class

How it says: "there is no limit to perfection" - [new wrapper][1]. Now it works like more native: ```js class PromiseClass { static async new(test='test'){ this.promise= test; return this;} constructor(...args) { let s = async()=>PromiseClass.new.call(this,...args); return (async r=>await s()

Re: Re: Async Class

>Not a bad idea, but I'd strongly prefer the promise to be returned from new >AsyncClass(...) itself instead This about wrapper? He is just example of how functional can work right now. >I do have a preference: async should decorate the constructor, not the class How i say before: both variants

Re: Re: Async Class

Not a bad idea, but I'd *strongly* prefer the promise to be returned from `new AsyncClass(...)` itself instead. And down that vein, `super` with async classes should also implicitly `await` in its `super` call, setting `this` to the value itself. For sanity reasons, `super` should return a promise

Re: Re: Async Class

Ok so much time has passed. I have learned more js. And created some [wrapper][1] for my idea: Class is just function constructor that return object Async Class is async function constructor that returns promise object. Wrapper code: ```js class PromiseClass { //promisified class static async

Re: [Proposal] Optional spreading

On 23. 8. 2019 16:24, Beknar Askarov wrote: @Scott Rudiger After thinking more about it. I would not like to conflict with semantics of optional chaining and null coalescing operator. So in order to not confuse people, maybe introduce two types of optional spread operators 1. `?...` - Do

Re: [Proposal] Optional spreading

@Scott Rudiger After thinking more about it. I would not like to conflict with semantics of optional chaining and null coalescing operator. So in order to not confuse people, maybe introduce two types of optional spread operators 1. `?...` - Do not spread if nullish. Note nullish. Else try to

Re: [Proposal] Optional chaining

Another similar thing I've used is with String interpolation; if you use a similar pattern, e.g., ``` `$[items.length} item${items.length !== 1 ? 's' : ''} in collection` ``` When you want to conditionally add either some text, or nothing at all, you are forced to use the ternary with an empty

Re: [Proposal] Optional spreading

Like others said, this idea is good, but I think we can already achieve something decent and succinct enough arrays: ```js // group by name, and accumulate data: arr.reduce((m, {name, data, ...o}) => m.set(name, {...o, data: [...m.get(name)?..data||[], ...data]}), new Map()) ``` objects: `{foo:

Re: [Proposal] Optional spreading

And it does result in empty array [...''] -> [] So not much difference even if it passes through. Everything else would result in error if check was only nullish On Fri, 23 Aug 2019, 04:55 Beknar Askarov, wrote: > @Scott My mistake empty string [...""] is spreadable. > But not sure if it is

Re: [Proposal] Optional spreading

@Scott My mistake empty string [...""] is spreadable. But not sure if it is desirable behavior. On Fri, 23 Aug 2019, 04:42 Beknar Askarov, wrote: > Indeed. I see your point. > > But it really needs to be falsy check. > Since falsy values are not "spreadable" > > > > On Fri, 23 Aug 2019, 03:52

Re: [Proposal] Optional spreading

Indeed. I see your point. But it really needs to be falsy check. Since falsy values are not "spreadable" On Fri, 23 Aug 2019, 03:52 Scott Rudiger, wrote: > I like it; code seems cleaner to me with its use. However, since the > syntax is so similar to optional chaining, it's too bad your goal

Re: [Proposal] Optional spreading

Since you can do this now with: ```js [ 1, ...(condition ? [2, 3] : []), 3, ] ``` and object spreading already handles this for you, is extra syntax really needed? On Thu, Aug 22, 2019 at 6:52 PM Scott Rudiger wrote: > I like it; code seems cleaner to me with its use. However, since the

Re: [Proposal] Optional spreading

I like it; code seems cleaner to me with its use. However, since the syntax is so similar to optional chaining, it's too bad your goal with this sample is to check for falsey values rather than nullish values. [ 1, ?...(condition && [2, 3]), // no extras:) 3, ] On Thu, Aug 22, 2019, 6:01 PM

[Proposal] Optional chaining

Problem Spreading is great! It contributes towards "declerativity" of the language and reduces verbosity. I see one more feature to add to improve it. Consider following [ 1, condition && 2, condition && 3, 4, ].filter(Boolean) // filtering needed to remove falsy values // Results in

Proposal-index-from-end array[^n]

There has been many "array.last()" and similar proposals on es-discuss One has emerged: https://github.com/keithamus/proposal-array-last It adds Array.prototype.lastIndex and Array.prototype.lastItem I'd like to extend this idea with a syntax like `arr[^n]` (stands for `arr[arr.length - n]`), I

Re: Proposal: Range Expression

Here is a PR for adding SliceExpression to proposal-slice-notation (that could probably be renamed proposal-slice-expression if it's accepted) https://github.com/tc39/proposal-slice-notation/pull/32 On Mon, Aug 19, 2019 at 10:29 AM Cyril Auburtin wrote: > I'd prefer to have it in slice-notation

Re: Array.prototype.joinWith(iterable)

OK thanks for the link On Mon, 19 Aug 2019 at 11:41, Andrea Giammarchi wrote: > Naveen, please read more about template literals tags, thanks. > > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#Tagged_templates > > On Mon, Aug 19, 2019 at 12:16 PM Naveen

Re: Array.prototype.joinWith(iterable)

Naveen, please read more about template literals tags, thanks. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#Tagged_templates On Mon, Aug 19, 2019 at 12:16 PM Naveen Chawla wrote: > HTML tags? Afraid I still don't get that aspect. Perhaps my reading style

Re: Modulo Operator %%

Another typical example: ```js const normalizeHue = hue => (((hue % 360) + 360) % 360) / 360; // phew.. // would become: const normalizeHue = hue => (hue %% 360) / 360; ``` On Sat, Aug 17, 2019 at 9:54 PM Isiah Meadows wrote: > BTW, that very example is something I cover in my proposal's >

Re: Array.prototype.joinWith(iterable)

HTML tags? Afraid I still don't get that aspect. Perhaps my reading style is not matching your writing style. I understood everything else. I would still need a really simple example(/s) completed with sample input data from start to finish (for tags). Anyway from what I'm seeing so far I think

Re: Where is the evaluation starting point in the spec?

On 2019-08-17 23:03, Gus Caplan writes: It's worth noting that engine262 doesn't use the RunJobs implementation it has, it uses a separate entrypoint in api.mjs. There is some work going on to get rid of RunJobs entirely, as no implementations actually use it (

<    1   2   3   4   5   6   7   8   9   10   >