It is not clear if it was originally intended to be different. One way to look at it is that an async block is similar to a closure, and thus it seems like parsing them in a similar way makes some sense.

Syntactically, it just means that when used as a statement, it must end with ;, in a match arm end with a ,. In practice this is almost never an issue since it is usually followed by .await. One could also argue that it helps avoid a mistake such as:

async {/*...*/} // Oops, async block doesn't actually do anything.
println!("hi"); // ERROR: expected ;

See #1267 for more context.

I do not know how to respond to that.

So far (from what I gathered from the context that you linked) the only difference between two options is whether require a ; for async block to be used as an expression statement, and to classify and definitively decide that the language has to have this specific production rule just because of the semicolon seems frivilous.

Just consider the cognitive load on the users of the language. The features should be orthogonal and respect the principle of least surprise. I think we should tell a consistent story. We have normal blocks, then in order to operate on unsafe contexts we can use unsafe blocks, and similarly in order to operate on asynchronous contexts we can use async blocks. And this story is extensible, in the future we can say, in order to operate on fallible contexts we can use try blocks. And the consistent story should be the uniform one. We should be able to say that unsafe blocks, async blocks, try blocks are syntactically same, only semantic difference stems form the context they introduce, i.e unsafe async and fallible context.

On the other hand, current implementation seems to parse the expression as written in the current reference. So, if the purpose of the reference is to document the reference implementation there is nothing else to say. But if we think of a Rust language separate from the reference implementation and the reference documenting the language not the implementation, I think there must be a discussion and agreement among the language designers and implementors. And presumably that conclusion should not be based on semicolons but general language design principles.

But I am not sure if here is the place to have that discussion. So, I do not know how to respond.

https://internals.rust-lang.org/ is usually the place to go if you want to discuss the design of the language. Generally the reference describes what rustc implements.

async blocks are distinctly different from other kinds of blocks since they are not executed, but instead create a value that can be executed. I understand it can seem a little odd since syntactically they look so similar to other blocks kinds. However, they are quite different semantically.

For users, I doubt this syntactic difference will ever register or need to be understood. I think it should only really matter to parser writers and language lawyers.

Thank you for your comments. They were very helpful clarifying the issue.

Since the reference follows the implementation and it correctly describes actual behaviour of the implementation, there is no reason to keep this issue open.

Thanks again!