Would you mind, please, explaining how it helps us understand the behavior of this trivial example? I'm sorry if you think it should be obvious, but it truly isn't to me. I started this thread because I want to understand this stuff better.
And we need to be very careful of reasoning from simple examples.
I'm also trying understand what your point might be here. If, as you say, even this trivial example demonstrates that await is helping, I personally will be very glad to reason from it that await is just as valuable in the parallel case as in the interleaved concurrent case, and that would leave very few questions on the table about why we have it (fair warning: I’ll probably ask whether it should be one keyword or two in that case, though).
I disagree with the entire premise of this thread. The case that
awaitis unnecessary relies on programs having complete surety of the invariants of their system, which we know isn't the case.
Sorry to contradict, but that is not the premise of the thread. This is an exploration of some possible design trade-offs, and a search for the best balance in addressing what some of us see as a problem.
To accept that
asynccalls would be unannotated means thattrywas such a problematic mis-step that we're willing to have an inconsistency in the language betweenasyncandthrows.
Actually no. We've been talking in this thread about giving the programmer control over the granularity of try using various forms of try block: either try {...} or try do {...}. If async ends up having a similar signal value in the programming model to try, consistency could be maintained by allowing async to join or replace try in those syntaxes.
But my hunch that async and try have the similar signal value characteristics hasn't played out so far. In that case it is a totally legitimate question whether we'd be better off not solving the problems that motivated this thread, or breaking syntactic uniformity, and the right answer isn't obvious to me yet.
I see no path for async/await without the await, and I do not believe it is worth the effort to go try to build a brand new constructive argument of why
awaitis important given the precedent and general acceptance oftryin Swift.
I @-mentioned you to ask for some facts about the proposals, but that wasn't intended to drag you into a discussion that you consider to be a waste of time. I’m digging into these questions because I think it’s an important part of the language design process, and the process of learning how to use the language we ultimately design. Even if it were a foregone conclusion that we have granular await everywhere, I’d want to crisply identify its role in the programming model. That will help me use Swift more effectively, and more importantly, teach others to do so.