Code change:
let lo = self.token.span; if !self.eat(&token::OpenDelim(token::Brace)) { <del> let sp = self.token.span; let tok = self.this_token_descr(); let mut e = self.span_fatal(sp, &format!("expected `{{`, found {}", tok)); let do_not_suggest_help = self.token.is_keyword(kw::In) || self.token == token::Colon; if self.token.is_ident_named(sym::and) { e.span_suggestion_short( self.token.span, "use `&&` instead of `and` for the boolean operator", "&&".to_string(), Applicability::MaybeIncorrect, ); } if self.token.is_ident_named(sym::or) { e.span_suggestion_short( self.token.span, "use `||` instead of `or` for the boolean operator", "||".to_string(), Applicability::MaybeIncorrect, ); } </del> <ins> return self.error_block_no_opening_brace(); } </ins> <del> // Check to see if the user has written something like // //    if (cond) //      bar; // // which is valid in other languages, but not Rust. match self.parse_stmt_without_recovery(false) { Ok(Some(stmt)) => { if self.look_ahead(1, |t| t == &token::OpenDelim(token::Brace)) || do_not_suggest_help { // If the next token is an open brace (e.g., `if a b {`), the place- // inside-a-block suggestion would be more likely wrong than right. e.span_label(sp, "expected `{`"); return Err(e); } let mut stmt_span = stmt.span; // Expand the span to include the semicolon, if it exists. if self.eat(&token::Semi) { stmt_span = stmt_span.with_hi(self.prev_span.hi()); } if let Ok(snippet) = self.span_to_snippet(stmt_span) { e.span_suggestion( stmt_span, "try placing this code inside a block", format!("{{ {} }}", snippet), // Speculative; has been misleading in the past (#46836). Applicability::MaybeIncorrect, ); } </del> <ins> self.parse_block_tail(lo, BlockCheckMode::Default) } fn error_block_no_opening_brace<T>(&mut self) -> PResult<'a, T> { let sp = self.token.span; let tok = self.this_token_descr(); let mut e = self.span_fatal(sp, &format!("expected `{{`, found {}", tok)); let do_not_suggest_help = self.token.is_keyword(kw::In) || self.token == token::Colon; if self.token.is_ident_named(sym::and) { e.span_suggestion_short( self.token.span, "use `&&` instead of `and` for the boolean operator", "&&".to_string(), Applicability::MaybeIncorrect, ); } if self.token.is_ident_named(sym::or) { e.span_suggestion_short( self.token.span, "use `||` instead of `or` for the boolean operator", "||".to_string(), Applicability::MaybeIncorrect, ); } // Check to see if the user has written something like // //    if (cond) //      bar; // // which is valid in other languages, but not Rust. match self.parse_stmt_without_recovery(false) { Ok(Some(stmt)) => { if self.look_ahead(1, |t| t == &token::OpenDelim(token::Brace)) || do_not_suggest_help { // If the next token is an open brace (e.g., `if a b {`), the place- // inside-a-block suggestion would be more likely wrong than right. e.span_label(sp, "expected `{`"); return Err(e); </ins> } <del> Err(mut e) => { self.recover_stmt_(SemiColonMode::Break, BlockMode::Ignore); e.cancel(); </del> <ins> let stmt_span = if self.eat(&token::Semi) { // Expand the span to include the semicolon. stmt.span.with_hi(self.prev_span.hi()) } else { stmt.span }; if let Ok(snippet) = self.span_to_snippet(stmt_span) { e.span_suggestion( stmt_span, "try placing this code inside a block", format!("{{ {} }}", snippet), // Speculative; has been misleading in the past (#46836). Applicability::MaybeIncorrect, ); </ins> } <del> _ => () </del> } <del> e.span_label(sp, "expected `{`"); return Err(e); </del> <ins> Err(mut e) => { self.recover_stmt_(SemiColonMode::Break, BlockMode::Ignore); e.cancel(); } _ => {} </ins> } <del> self.parse_block_tail(lo, BlockCheckMode::Default) </del> <ins> e.span_label(sp, "expected `{`"); return Err(e); </ins> } /// Parses a block. Inner attributes are allowed.

Related discussion:
text: Also, the problem isn't that people may choose to put just for the heck of it, but that they will unintentionally mutate something that was supposed to be immutable. And because it is being mutated, there is no warning, and they used because it is their default, it is their default because it gets rid of compiler errors that say they were trying to mutate things that are immutable even though they weren't supposed to mutate them in the first place. They will use because it is just as easy as making it immutable. So the problem is a bit more subtle than you seem to think.
Incorrect. Extreme brevity harms readability. See Perl. lol Readers would ignore the vs distinction far more often that vs , partially due to length difference, but works even better than say . It's true boilerplate often harms readability, but boilerplate requires some complexity be repeated, not merely the in . It harms readability even further if also works for , especially when you consider code readers need not actually know Rust. Rust syntax was designed largely to reduce cognitive load, not to reduce typing. We use , , and , not any shorter alternatives. And delegation RFCs have kinda given up the short syntaxes. I think Rust's omission of is now considered a mistake, but presumably helps C programmers. Rust has short keywords only really for fundamental "items" used repeatedly by basically every module. It's similar cognitive load if you write , , or , but actually just writing the shorter bare increases cognitive load. I think invokes the minor linguistic subtlety that variable means mutable binding, while acts like a common term for binding, which makes very slightly clearer.
The statement would be orthogonal to the current language in some sense though. is not a special syntax, but is composed of statement + pattern. It is in line with other places expects a pattern, where you can write , , or .
It seems unlikely to me that we would support as a short-hand. I'm personally opposed to it both because it adds unnecessary compiler complexity, stylistic schisms, and for the reasons outlined by However, I've taken the liberty of reusing this issue towards improved diagnostics: The idea here is to check . The idea here is to check: The relevant code is here: cc
claim
Error: Parsing assign command in failed: claim :)... Please let know if you're having trouble with this bot.