Earlier quoted context omitted.
It is okayish in TypeScript, but in js one subtle missing await also leads to unexpected everything. Mass-await in a language without types is a bad idea generally, but we have no alternatives for “the web”.
It's not a problem with types. It's a problem with call semantics. If `foo()` behavior depends on whether `foo` is async or not, you're implicitly introducing yield points that might lead to bugs like race conditions. Even worse: if you're calling a sync function and you (or a library author) turns it into an async function, it will silently introduce the yield point without anybody noticing. Both sync and async `foo…
You may still have race conditions with await. It doesn’t prevent anything, though I see your point if we are talking about flow control (not just net/io) via coroutines. That is race-prone in general, but most of the code is a non-leaking ‘let; await fetch(); return’ in one way or another. If someone is writing code like:
public_state = a
[await or autoawait] task()
public_state = b
Both sync and async `foo()` would return a `T` so TypeScript won't help with that.
async function foo(): Promise {
return "foo"
}
async function bar() {
var s:string
s = foo()
}
Type 'Promise' is not assignable to type 'string'.