In my previous post I said that the lang team would be making our final decision about the syntax of the await operator in the May 23 meeting. That was last Thursday, and we did reach a decision. In brief, we decided to go forward with the preliminary proposal I outlined earlier: a postfix dot syntax, future.await. For more background, in addition the previous post on my blog, you can read this write up about some of the trade offs from April.

There are a few things I want to make clear about this proposal and about our design process in general.

First, there a very few absolutes in the design of the Rust language. There are a few things we can’t do (or must do) - our type system must be sound, for example. But the vast majority of questions are questions of trade offs - weighing the pros and cons of different proposals to find the path forward we believe is most preferable. Often, there is a choice that is clearly superior to just about everyone. But sometimes all of the proposals have different positive and negative attributes, and the way each of us weighs those attributes is different, leading to conflicting opinions. This was certainly one of those times.

I’ve seen in these discussions costs that people weigh heavily raised to the level of absolutes. This negative attribute of some proposal is held to be so bad that we simply can’t do that. For the most part, this is an unhelpful framing. It closes the discussion because it makes it difficult for people who disagree to acknowledge that this problem is real while also arguing that we should hold a different balance of the cost, which makes it still the preferable choice. We need to be able to avoid this sort of dichotomizing, black and white thinking.

And as an additional addendum to this idea, each member of the language team weighs these costs differently. Individually, several of us might have made a different selection than the syntax we have chosen here. I know that the way I weigh the costs personally, it is not my most preferred proposal. But we are all united in the desire to move forward with providing the feature that users need and the understanding that several of these proposals are viable. This decision has been justified well and reflects the “consensus weighting” of the different costs among the members of the language team. If you weighted these costs such that you would have made a different choice, I would like to imagine that you can also embrace these values and feel glad that we are moving forward.

There are a few further clarifications regarding some conversations that have arisen in the discussion the last few weeks:

• “Dot keyword:” In the previous post, a sketch was made of an idea in which certain keywords could be postfixed or infixed using the dot operator. This idea is only a sketch, and is not implied or guaranteed by the decision we’ve made here. While this operator might provide some additional motivation for that proposal, it will still need to go through its own RFC process, and has its own clear drawbacks that users have already identified that will need to be weighed separately from this decision.
• Sigil syntaxes: In the previous summary, sigil syntaxes like @await were only very briefly addressed. I want to be clear that this is once again a question of weighing costs. The costs of introducing a new sigil with meaning in the language are real: we only have so many sigils available (non-ASCII sigils are not considered viable from an input accessibility perspective), each new sigil increases the surface area that users need to learn, using overmany sigils is considered aesthetically unpleasant by many people. Comparing the costs of using a new sigil to the costs of reusing the already overloaded . operator, we felt that using . was less costly. Some users may disagree, but I hope you can understand that this isn’t a black and white question, but a comparison of options each with their own pros and cons.

Next steps

I’m working actively on drafting a stabilization report to propose stabilizing a minimum viable version of async/await in the 1.37 release of Rust. 1.37 will be released in mid-August, and branches on July 4. That means we have about a month to make sure the implementation, documentation, and design are all in a sufficient state to stabilize the minimum version of this feature. That won’t be the end of the async/await feature - there will be a lot of extensions left out of the minimum feature - but it will be an important milestone for everyone who wants to use Rust for high performance network services.