This is an alternative to cancellable promises that relies entirely on
existing JavaScript.
I'm posting this here in hopes to bring the discussion back to practical
use cases and minimal needs.
Example:
Here's a setTimeout wrapper with cancellation, using a regular promise
as a cancellation
await* would be cool, even if it saves just 10 chars.
2016-10-26 13:14 GMT+02:00 Andrea Giammarchi :
> > in case of rejecton, other promises don't get cancelled/reverted
>
> **yet**, since cancelable Promises is something already available in
> bluebird and it will eventually land on JS land too
Hi!
Inspired by what I just did in Amber Smalltalk workspace:
Smalltalk packages do: #commit
Eg., selector symbol #commit acting as an [ :x | x commit ] block, would
it be feasible (it only saves 6 chars of nicely formatted "x => x", so
maybe no) to have a similar shortcut in ES, as in:
> in case of rejecton, other promises don't get cancelled/reverted
**yet**, since cancelable Promises is something already available in
bluebird and it will eventually land on JS land too (it'd be about the
time, `Promise.all` is indeed yet another use case for cancelability)
So yeah, `Promise.al
You avoid only few very limited cases of parallelism.
When you use Promise.all you are awaiting either on *all promises to
resolve or first rejection*, but in case of rejecton, other promises don't
get cancelled/reverted. That's pattern not present in synchronous code.
Awaiting on values is more s
avoiding parallelism? can you please elaborate a bit more what's the code
smell, exactly?
On Wed, Oct 26, 2016 at 10:49 AM, Michał Wadas
wrote:
> Actually using Promise.all with async/await is usually code smell - you
> probably should await on values.
>
>
>
> On Wed, Oct 26, 2016 at 10:40 AM, D
Actually I think symbol name interference should be left as implementation
detail. So I would change 19.4.1.1 § 2 to allow implementations for custom
behavior.
On Tue, Oct 25, 2016 at 12:45 PM, Shahar Or
wrote:
> So, we have function name inference, like
>
> ```
> const funcs = { foo: () => {} }
Actually using Promise.all with async/await is usually code smell - you
probably should await on values.
On Wed, Oct 26, 2016 at 10:40 AM, Damian Senn wrote:
> I don't like the `await* []` syntax, it doesn't really tell me what it's
> doing.
> I could imagine something like `await.all []` or `
I don't like the `await* []` syntax, it doesn't really tell me what it's
doing.
I could imagine something like `await.all []` or `await.race []` desugaring
to `await Promise.all([])` and `await Promise.race([])`, this could also be
expanded to whatever new functionality might be added in the future
Personally, I wouldn't mind such an operator, as I feel that the use of
`Promise.all` clearly
outweighs all other `Promise` combinators, but this could be an opinionated
view.
IIRC, that even was up for standards discussion at some point (being called
`await*` instead
of `await`). I'm not sure
Right it makes sense, should have thought about that! An `awaitAll` (or
other syntax) could be nice but it seems the general opinion is against.
On Wed, Oct 26, 2016 at 1:22 AM, kdex wrote:
> It's especially beneficial for designing APIs where you don't care about if
> users pass you a `Promise`
It's especially beneficial for designing APIs where you don't care about if
users pass you a `Promise` or the actual data to work with.
Imagine a scenario where you would like to remove a set of files:
```js
async function remove(filesArray) {
const files = await filesArray;
/* …
I didn't realize `await` could be used on non-`Promise`s, never mind. I
wonder why that is, seems strange. Maybe so that async functions could be
more easily swapped out with sync ones in code? I do think `Promise.all`
should deserve special treatment because it is so common, unlike
Promise.race (w
Oh, I didn't realize `await` could be used on non promises :( Never mind, I
guess!
On Wed, Oct 26, 2016 at 12:30 AM, kdex wrote:
> This change is not backwards-compatible. Note that the semantics of the
> following example would change:
>
> ```js
> (async () => {
>const result = await [new P
This change is not backwards-compatible. Note that the semantics of the
following example would change:
```js
(async () => {
const result = await [new Promise(resolve => {
setTimeout(resolve, 1000);
})];
})();
```
Now, what should `result` contain?
`await` can already be used on non-
Your suggestion would preclude having a promise for an array (exactly what
`Promise.all` returns).
If you want `await` syntax for `Promise.all`, you'd need different syntax
for it - and then, what about `Promise.race`? What about other future
combinators?
On Wed, Oct 26, 2016 at 12:25 AM, Olivier
On Wed, Oct 26, 2016 at 10:25 AM, Olivier Lalonde
wrote:
> I don't think so, what do you mean?
>
Conceptually, await is similar to Promise.resolve and this similarity is
more useful than saving a few keystrokes.
___
es-discuss mailing list
es-discuss@m
I don't think so, what do you mean?
On Wed, Oct 26, 2016 at 12:22 AM, Raul-Sebastian Mihăilă <
raul.miha...@gmail.com> wrote:
> Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ?
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.
Then Promise.resolve([p1, p2]) should be like Promise.all([p1, p2]) ?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I have no idea if this has been discussed already but I thought it'd be
nice to have the following syntax sugar for async/await.
The idea would be that any array that follows `await` would be wrapped into
a Promise.all() call. For example, `await [p1,p2]` would be the equivalent
of `await Promise.
20 matches
Mail list logo
