{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicdqwxz7qljbl3h5c6p3svxiiiyq6cnajeohcbtkoyvg326wmbgci",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mm2dhbbhedf2"
  },
  "path": "/t/interiorassign-trait-a-b/24291?page=2#post_31",
  "publishedAt": "2026-05-17T11:32:48.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[1]",
    "@RustyYato",
    "::cell_project",
    "(click for more details)",
    "[3]",
    "↩︎"
  ],
  "textContent": "Can't help but think of this :\n\n* * *\n\nMore seriously, regarding the OP:\n\nSyntax to alleviate the `.borrow_mut()` of `RefCell`, _a function which may panic_ , ought probably not to benefit from sigil sugar. Granted, we do have an elephant-in-the-room exception here, being the `[…]`-indexing, but that's a historical inheritance which is already expected not to be used in the out-of-bounds case in other languages, either \"throwing an exception\" or straight out triggering UB. (And some could even advocate that `[…]`-paicking-indexing is not the best example of wise API design.)\n\n  * moreover, if `->` syntax were to be used somewhere in Rust, I'd imagine that C/C++'s `(*lhs).rhs` would be its intended semantics, both to avoid least surprise, and also because not having a purely postfix syntax for this operation does hurt `unsafe`-Rust-writing (although, granted, we could also consider this \"syntax overhead\" to be a feature too )\n\n\n\nOTOH, the syntax overhead of `Cell` in Rust, is most definitely an _unwarranted limitation_. Not a big one, but big enough to deter too much people from using it.\n\nAs a reminder, the best way to transpose the (non-`NULL`) `T *` mutable pointer of C/C++, or the `T &` mutable reference of C++, is with Rust's `&Cell< T >`: the mutable, but aliased-and-copyable, reference.\n\nIt would be perfectly conceivable[1] for Rust to expose this construct as a first-class citizen: `&cell` references; and take the opportunity to offer extra niceties alongside it, such as `&cell`-projection, as showcased by @RustyYato's ::cell_project.\n\nsome musings, click to see (click for more details)\n\nAll that to say that in such a world, having some form of syntactic sugar for `Cell::get()`, as well as `Cell::set()` and/or `Cell::replace()`, could also be envisioned and quite welcome.\n\n  * OTOH, I don't think it would be wise to offer a generalization of this functionality through a whole layer of trait abstraction; rather, it would be specific to the `&cell` case, and it being a special kind of Rust reference, alongside, `&` and `&mut`[3]\n\n\n\n* * *\n\n  1. why is \"envisionable\" not a word  ↩︎\n\n  2. OTOH, assuming all the `Vec` resizing or `.pop()`ing-like operations to be `&mut self`-based, then perhaps an `fn get_cell(self: &cell Vec<T>, idx: usize) -> Option<&cell T>` could be envisioned?  ↩︎\n\n  3. and `&pin [mut]`, as well as `&own` (and perhaps `&out` ) ↩︎\n\n\n",
  "title": "InteriorAssign trait { a := b }"
}