As someone who originally was for the foo.await!() and foo@await syntaxes, and vehemently against the field access syntax, this post was originally very concerning. However this post did an excellent job of explaining your position. You did a very good job of covering all major positions not brought up by the team. I now feel that macro syntax is not the way to go, and that a keyword is necessary.
I originally was afraid of the syntax highlighting story, but I forgot that rust employs await as a strict keyword, thus making it trivial for syntax highlighting to work correctly. I also was afraid of potential compiler confusion by not using a special sigil instead of merely dot, but in combination with the opinion of the language team that this syntax should be feasible:
foo.bar(..).baz(..).match {
Variant1 => { ... }
Variant2(quux) => { ... }
}
and the strict keyword restriction, the sigil holds no value to me now, and I now agree, it is just noise. Part of the justification of the sigil was to promote a general pipelining syntax. What is more, this doesn't preclude a potential UMCS feature if needed, and would fit right in.
I now feel after this post that .field syntax is the best possible syntax for rust. I do think, however, there is a lot to discuss about the communication break-down that happened between the language team and the community previous to this.
There's the obvious, the fact that you guys discussed things internally, and already moved passed ideas the community re-argued about even though they were dead in the water. I think that is a rather simple lesson to learn from, log even more ideas you previously considered and rejected.
Then there's the massive confusion on whether await was implemented as a macro, a function, a compiler implemented thingy, and that still exists. I've seen people tell me "this is not a macro" and then say it is more a of a function when it clearly wasn't. We literally have an await macro, and that makes things even more confusing. We have an issue about the error messages of the await macro, and a claim that this why it couldn't be implemented as a macro, and that it was the only reason, it wasn't. You might have wanted to have a post on this in its own right.
The least straight forward communication failure to fix is how opaque the issues are around rusts tool-set, and how the compiler, well, actually works. With out a zeitgeist of community understanding of how the rust compiler actually works, we can't know the potential parsing issues, we either have to take the language teams word for it that "X isn't going to be a parsing issue", apply our knowledge from what other compilers do, or be an expert on rusts compiler in our own right. What is more concerning, is that the community has no collective idea about the issues of the proposals they themselves brought forth. Solutions that just won't work for one reason or another will have runaway support. With things like space await syntax, we just aren't going to know anything like this:
- Postfix space expressions can cause problems with compiler recovery when the user omits a necessary semicolon (that is, they can result in the compiler giving much less helpful error messages); we’d like to avoid them without a compelling motivation.
with out compiler knowledge. And what is more, we are now going to hold your word as scripture. We will likely apply this logic to where it doesn't belong at all, causing more confusion. Knowledge about compiler restrictions and how hard it is to do, or modify something in the compiler needs to be more common, and that just isn't happening, even with the compiler team videos. You don't need to have everyone understand it, but you do need to have more people be able to give educated arguments on why you can or can't do something because of the compiler.