{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicyle5d6rcnugleehp2j3fefap4kogorxzvg2ubujbvtqwrrjn54q",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mh6p5i7wwnu2"
  },
  "path": "/t/just-mut-alongside-let-mut/24084#post_6",
  "publishedAt": "2026-03-15T20:19:22.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "Frequently Requested Changes - The Rust Language Design Team"
  ],
  "textContent": "See also: Frequently Requested Changes - The Rust Language Design Team\n\n> ## Frequently Requested Changes\n>\n> This page documents some of those ideas, along with the concerns that argue against them.\n>\n> If something appears on this page, that doesn’t mean Rust would _never_ consider making any similar change. It does mean that any hypothetical successful proposal to do so would need to address _at a minimum_ all of these known concerns, whether by proposing a _new and previously unseen_ approach that avoids all the concerns, or by making an _extraordinary_ case for why their proposal outweighs those concerns.\n>\n> Hopeful proposers of any of these ideas should document their extensive research into the many past discussions on these topics and ensure they have something new to offer.\n>\n> _[…]_\n>\n> ### Fundamental changes to Rust syntax\n>\n> This includes proposals such as changing the generic syntax to not use `<`/`>`, changing block constructs to not require braces, changing function calls to not require parentheses, and many other similar proposals. These also include proposals to add “alternative” syntaxes, in addition to those that replace the existing syntax. Many of these proposals come from people who also write other languages. Arguments range from the ergonomic (“I don’t want to type this”) to the aesthetic (“I don’t like how this looks”).\n>\n> Changes that would break existing Rust code are non-starters. Even in an edition, changes this fundamental remain extremely unlikely. The established Rust community with knowledge of existing Rust syntax has a great deal of value, and to be considered, a syntax change proposal would have to be not just _better_ , but _so wildly better_ as to overcome the massive downside of switching.\n>\n> In addition, such changes often go against one or more other aspects of Rust’s design philosophy. For instance, we don’t want to make changes that make code easier to write but harder to read, or changes that make code more error-prone to modify and maintain.\n>\n> That said, _we are open to proposals that involve new syntax_ , especially for new features, or to improve an existing fundamental feature. The bar for new syntax (e.g. new operators) is high, but not insurmountable. But the bar for _changes to existing syntax_ is even higher.",
  "title": "Just `mut` alongside `let mut`"
}