Conditional await, anyone?

#!/JoePea joe at
Sat Nov 16 17:58:44 UTC 2019

I haven't read the whole thread, but I also disliked the ugly
conditional checking I had to do to get faster results.

I agree that this would changed perceived code execution order
(unexpectedly, a breaking change).

I believe that a better solution would be to make it explicit in the
function definition, so that it carries up into caller code:

async? function foo() { ... }

Now, the user of the function must be required to use `await?` and
thus has to be forced to think that the `foo` function might possibly
run async, or might not. Using `await` on an `async? function` would
be a runtime error, to further prevent possible confusion and errors.

Only with a construct like `async? function` could I see this becoming
possible, so that there aren't any surprising breaking changes in
downstream projects.

On Tue, Oct 15, 2019 at 12:26 AM Andrea Giammarchi

<andrea.giammarchi at> wrote:
> > You still seem to be misunderstanding what the execution order difference is about.
> If to stop this thread you need me to say I am confused about anything then fine, "I am confused", but if you keep changing my examples to make your point then this conversation goes nowhere, so I am officially out of this thread.
> Best Regards.
> On Mon, Oct 14, 2019 at 10:41 PM Tab Atkins Jr. <jackalmage at> wrote:
>> On Sat, Oct 12, 2019 at 7:19 AM Andrea Giammarchi
>> <andrea.giammarchi at> wrote:
>> > 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.
>> That's definitely not true. I gave you an explicit example where the
>> order differs. That example code is realistic if you're using the
>> async call for side-effects only (and thus don't care about the
>> returned promise), or if you're storing the returned promise in a
>> variable so you can pass it to one of the promise combinators later.
>> In either of these cases the order of execution between the sync and
>> async code can definitely 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);
>> > ```
>> In both of these cases, you're doing no additional work after the
>> "maybe async" point. That is the exact part that moves in execution
>> order between the two cases, so obviously you won't see any
>> difference.  Here's a slightly altered version that shows off the
>> difference:
>> ```js
>> (async () => { 1; console.log("async"); return 3; })().then(console.log);
>> console.log(2);
>> (async () => { await 1; console.log("async"); return 3; })().then(console.log);
>> console.log(2);
>> ```
>> In the first you'll log "async", "2", "3". In the second you'll log
>> "2", "async", "3".
>> > 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.
>> You still seem to be misunderstanding what the execution order
>> difference is about. Nobody's confused about the syntax; it's clear
>> enough. It just does bad, confusing things as you've presented it.
>> As I said in earlier message, there *is* a way to eliminate the
>> execution-order difference (making it so the only difference would be
>> the number of microtasks when your function awaits *multiple* sync
>> values), which I thought you'd come up with at some point, but I'm
>> pretty sure it was just me misunderstanding what you'd said.
>> ~TJ
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list