A final proposal for await syntax

A postfix await keyword with an alternative sigil (other than . dot) seems to have much more ongoing interest and support than is represented in @withoutboats' blog post or @nikomatsakis' summary of these proceedings.

From the prior dropbox paper on postfix syntax:

Unusual other syntaxes: Use a more unusual syntax which no other construction in Rust uses, such as future!await.

If that was indeed the best of the "unusual syntax" considered, then its not surprising it was subsequently dropped. Repurposing ! in this way would seem to have all sorts of parsing problems, for human and compiler alike. What I hadn't seen until recently, was that this syntax debate has been ongoing in various corners for well over a year, including:

RFC 2442: Simple postfix macros, comment by @withoutboats:

Method syntax today is a type dispatched resolution system and macros are not today type dispatched. This has always been the reason we have not supported method syntax macros. This RFC proposes to resolve this issue by giving up the connection between method syntax and type dispatched resolution. I think that is a significant loss, and I am not convinced that the usefulness of postfix macros justifies that change to the language.

[...]

Finally, I don't think await!() is a strong motivation for this RFC. The async/await RFC has await!() as a compiler built in to avoid deciding on the final syntax, but await expressions are not macros and can have whatever syntax we like.

How is it that method call syntax is sacred, but field access syntax is not so sacred?

Postfix is great, and yes we can keep the familiar await keyword. Just by changing the leading sigil away from . dot, we can avoid confusion with field access and gain clarity that this is a very special feature.

future¡await

Suggested Rust-specific nickname for U+00A1 ¡: postbang.

Rust source code is UTF-8, and going beyond ASCII has the unique advantage of a sigil character with zero prior or current use in the language. RFC 2457: Allow non-ASCII identifiers has been accepted though is not yet implemented. Since ¡ is punctuation, it also isn't available as a regular identifier character under this RFC. Postbang ¡ is as easy to type for many world users as ~ or ^. Its clearly marked on even the US-International keyboard layout.

Since ¡await would initially only appear in async fn's and blocks, ¡ postbang might only ever be used for this purpose. However, it could also later be expanded as a generic named-postfix operator sigil (implemented by macro or compiler built-in) or even for universal pipelining. For example, a postfix ¡try could have been done this way, it if was deemed essential to keep the "try" word in place. (But don't get me wrong, I like how postfix ? turned out.)

✓ avoids any possible confusion with field access or function call

✓ has no current language use, including with RFC-2457

A more substantial Fuchsia inspired example:

future@await

In the context of an async fn, where the await points just need to be annotated for the compiler's state machine surgery, @await also rings true for me.

✓ avoids any possible confusion with field access or function call

✓ Is a simple shift-accessible character on many keyboards, including US-international

✓ current use is limited to the pattern binding operator ident @ pat

A more substantial Fuchsia inspired example (by @magnet):

5 Likes