Keep in mind that having a degree of redundancy in the grammar helps IDEs and the compiler get its bearing when encountering malformed input. If you have the following code
let x = 42
let y = 0
the compiler can figure out that you're missing
;s because of this redundancy and will tell you so. That redundancy also helps human readers as well. Removing all redundancy from the grammar by removing sigils can make it nicer to write but the consequences of doing that can be far reaching and be a net negative to the real world user experience of writing code. This is similar to a proposal that props up every now and then of making
; optional, then it is much harder to figure out intent when we encounter
x = 42
y = 0
y are not previously defined. Did you mean
let x = 42? Did you mean
x = 42.y and you're missing the dot? It's not necessarily straight forward. Having visible delimiters helps not only the compiler but humans. Having different syntaxes for the same concept/feature makes the learnability of the language suffer.
The language also has a design constraint of having a regular grammar, not because
rustc can't have more advanced parsing (in fact
rustc supports a superset of Rust's grammar, in order to provide accurate suggestions in some occasions), but because we want to make life easier for third-party tools that might want to implement their own parsing.
The idea of delimiterless macros intrigues me and could be useful, but I think would fit with the language in a more cohesive way if it was tied to the not-yet-RFC postfix macros:
this.expr::<could<be, anything>>().postfix!, as the expression that is being operated on becomes much clearer (for both humans and