Does async/await solve a real problem?
a.d.bergi at web.de
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
The `await` keyword is definitely no "clutter".
Also have a look at this StackOverflow question&answer
<http://stackoverflow.com/a/25447289/1048572> 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.
More information about the es-discuss