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
>
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
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
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
*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
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,
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
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.
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
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
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
> 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](
12 matches
Mail list logo
