On Wed, Oct 9, 2019 at 12:08 AM Andrea Giammarchi
<[email protected]> wrote:
> I don't know why this went in a completely unrelated direction so ... I'll
> try to explain again what is `await?` about.
Nah, we got it. Our complaint was still about the semantics.
> ```js
> const value = await? callback();
>
> // as sugar for
> let value = callback();
> if ('then' in value)
> value = await value;
> ```
>
> The order is guaranteed and linear in every case, so that nothing actually
> change logically speaking, and the hint would be about performance, 'cause
> engines don't apparently optimize non-promise based cases.
Expand that code so there's a caller:
```js
function one() {
two();
console.log("one");
}
async function two() {
await? maybeAsync();
console.log("two");
}
```
What's the order of the logs?
If maybeAsync() is synchronous, then one() calls two(), two() calls
maybeAsync() which returns immediately, and it continues to log "two"
before ending and returning execution to one(), which then logs "one"
and ends.
If maybeAsync() returns a promise, then one() calls two(), two calls
maybeAsync() then freezes while it waits for the promise to resolve,
returning execution to one(). Since one() isn't awaiting the promise
returned by two(), it just immediately continues and logs "one" then
ends. At some point later in execution, the maybeAsync() promise
resolves, two() unfreezes, then it logs "two".
So no, the order is not guaranteed. It's unpredictable and depends on
whether the function being await?'d returns a promise or not. If you
don't know what maybeAsync() returns, you won't be able to predict
your own execution flow, which is dangerous and a very likely source
of bugs.
~TJ
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
