InteriorAssign trait { a := b }

Can't help but think of this :

More seriously, regarding the OP:

Syntax 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.)

• 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 )

OTOH, 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.

As 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.

It 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.

some musings, click to see (click for more details)

All 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.

• 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]

1. why is "envisionable" not a word ↩︎

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? ↩︎

3. and &pin [mut], as well as &own (and perhaps &out ) ↩︎