If it is truly sequential, then I see no need of an “await” keyword.
Every method call is already sequential. Control flow always waits for each line to complete before moving on to the next.
If we are going to introduce a keyword, then it should be to specify the thing that stands out and is different. Namely, there should be a keyword for “don’t wait”. In other word, a keyword for actual asynchronous execution in the background.
I see no benefit whatsoever to explicitly marking some calls as “wait for this to complete then do the rest of the stuff below it”, when in fact all code works that way.
If the execution order is linear and control flow moves down one line at a time, then that is the standard, normal, existing, basic operation model. That’s how things should work with no annotation, so we should not introduce an annotation that means “this works the normal way, just as it looks”.
If we want to eliminate the pyramid of doom, then just make it so we can eliminate it. As a programmer, I don’t care what happens internally, I don’t care how the compiler makes it happen, I already today don’t truly grok what the compiler does for normal code, I just know the result is indistinguishable from each statement being executed sequentially in source order.
If the compiler secretly transforms
B
C
D
into
B(completion: {
C(completion: {
D(completion: {
})
})
})
there’s no reason for me as a programmer to know about it or think about it or care about it. It should just work. I write B C D, and my program works as if those statements are performed one after another, just like I wrote them.
There’s no need or benefit to making me add extra cruft to tell the compiler to have them happen one after another, that’s already implied by the fact that they are sequential statements.