in order to work, `await` must be executed in an async scope/context
(either top level or within a closure).
In such case, either somebody is awaiting the result of that `async`
execution, or the order doesn't matter.
The following two examples produce indeed the very same result:
```js
(async () => { return 1; })().then(console.log);
console.log(2);
(async () => { return await 1; })().then(console.log);
console.log(2);
```
Except the second one will be scheduled a micro task too far.
Since nobody counts the amount of microtasks per async function execution,
the result is practically the same, except the second example is always
slower.
Putting all together:
```js
(async () => { return await 'third'; })().then(console.log);
(async () => { return 'second'; })().then(console.log);
console.log('first');
```
If you `await` the return of an async function, you are consuming that
microtask regardless, which is what `await?` here would like to avoid: do
not create a micro task when it's not necessary.
There's no footgun as the `await?` is an explicit intent from the
developer, so if the developer knows what s/he's doing, can use `await?`,
otherwise if the order of the microtask matters at all, can always just use
`await`.
As summary: the proposal was to help engines be faster when it's possible,
but devs are confused by the syntax, and maybeat the end there wouldn't be
as many benefits compared to the apparent confusion this proposal would add.
I hope I've explained properly what was this about.
Regards
On Fri, Oct 11, 2019 at 10:43 PM Tab Atkins Jr. <jackalm...@gmail.com>
wrote:
> On Fri, Oct 11, 2019 at 1:15 AM Andrea Giammarchi
> <andrea.giammar...@gmail.com> wrote:
> > Again, the `await?` is sugar for the following:
> >
> > ```js
> > const value = await? callback();
> >
> > // as sugar for
> > let value = callback();
> > if ('then' in value)
> > value = await value;
> > ```
>
> Okay, so that has the "you can't predict execution order any more"
> problem. But that's not consistent with what you said in "otherwise
> schedule a single microtask if none has been scheduled already, or
> queue this result to the previous scheduled one", which implies a
> different desugaring:
>
> ```js
> let value = callback();
> if('then' in value || thisFunctionHasntAwaitedYet)
> value = await value;
> ```
>
> *This* desugaring has a consistent execution order, and still meets
> your goal of "don't add a bunch of microtask checkpoints for
> synchronous values".
>
> Put another way, this `await?` is equivalent to `await` *if* you're
> still in the "synchronously execute until you hit the first await"
> phase of executing an async function; but it's equivalent to your
> simpler desugaring ("await only if this is a thenable") after that.
>
> > but since I've stated already I have no interest anymore in this
> proposal, we can also stop explaining to each others things we know already.
>
> I'm fine if you want to drop it, but we're not explaining things we
> already know to each other. At least one of us is confused about
> what's being proposed. And the altered desugaring I give up above at
> least has a chance of happening; the only issue might be the
> observability of how many microtasks get scheduled. If that's not a
> problem, it might be possible to suggest this as an actual change to
> how `await` works.
>
> ~TJ
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
