Does async/await solve a real problem?

Bergi a.d.bergi at
Sun Mar 29 23:17:05 UTC 2015

jordi baylina schrieb:
> I propose that all the calls to any async function will be  implicit
> (without the need of the await keyword). And precede it with a nowait only
> when you want a promise.
> This way, the code will not have the async clutter in the logic of the
> function, but will be need to be declared async advising the programmer
> that the code will not be executed atomically.

The problem with this is that the programmer cannot control those atoms.
He only sees that the function is `async`, but not where the async flow 
starts, pauses, or does anything else.
I don't understand whether your proposal only suggests to automatically 
await promises on function calls, or whether that should be done in 
every (sic!) single expression evaluation. The latter would be 
completely ridicolous, the former still be a hazard.

You really want to be explicit about yielding control. Everything else 
will call out for error-prone code, possibly breaking invariants that 
everyone expects to hold from looking at the code, just by random race 
conditions. You've never hunted a heisenbug, did you?
And with your proposal, you could not trust any single function call - 
they might completely change their behaviour (becoming async) without 
you noticing.

The `await` keyword is definitely no "clutter".

Also have a look at this StackOverflow question&answer 
<> where someone proposed a 
"use noblock" directive that would be very similar to your async 
functions. It has a nice example of such an unexpected race condition.

Kind regards,

More information about the es-discuss mailing list