Feedback was very positive on the concept of adding
await in general with a few key points raised:
- It was suggested that
try awaitreads better than
await try. The core team agrees, and the proposal will be modified accordingly.
- There was some discussion of alternatives to
suspends) which may better describe the meaning. The core team feels that the benefit of sticking with
asyncas a term of art with precedent in many other languages was preferable to the the slight descriptive benefit of alternative names. Note that other uses of
async letwill be considered in other proposals.
- Several reviewers expressed concern that it was hard to review this proposal "stand alone", since it interacts so closely with, and its use depends on, other yet-to-be-reviewed proposals. The core team acknowledges this, but feels that this is unavoidable given the large surface area of the whole concurrency feature. To mitigate this, reviewers of subsequent proposals should feel free to revisit parts of accepted concurrency proposals in reviewing those subsequent proposals when they interact.
- Several reviewers were disappointed about subsetting out getters. The core team wants to be clear that this is just left as a future direction, not ruled out, and as such isn't a reason to hold back on accepting this proposal.
- In a separate thread to the review, there was some discussion of the necessity of
await. The core team does not believe the current requirement to mark throwing calls with
tryshould be revisited, and thinks there is a similar need to mark possible suspension points with
await. The core team would be open to considering future proposals that allow multiple calls needing either
awaitto be sugared somehow (for example, some form of try block).
This is an important first step on our concurrency journey. To help navigate how this proposal relates to expected future proposals, this diagram should be of help:
Thanks to everyone who participated in the review!