RFC: Add RcMut<T> and GcMut<T> wrappers

[sfackler]

Working with mutable shared state is currently a bit gross. The crazy foo.borrow().borrow_mut().get().bar() stuff will be gone with auto-deref (yay!), but there's still the issue that a type like Rc<RefCell<T>> is gross looking and offputting to newcomers. I think a reasonable solution would be the introduction of some lightweight wrappers:

pub struct RcMut<T> {
    priv inner: Rc<RefCell<T>>
}

impl<T> RcMut<T> {
    pub fn new(t: T) -> RcMut<T> {
        RcMut { inner: Rc::new(RefCell::new(t)) }
    }

    pub fn borrow<'a>(&'a self) -> cell::Ref<'a, T> {
        self.inner.borrow().borrow()
    }

    ...
}

It's still deferring all of the heavy lifting to Rc and RefCell and should make downstream code cleaner at a pretty minimal cost.

Thoughts?

[emberian]

I'm hesistant to add extra wrappers. I'd rather prefer that we get type working better, so that we can say type RcMut<T> = Rc<RefCell<T>>. cc @pcwalton @thestinger

[alexcrichton]

I would be hesitant to do this, it seems to be favoring Rc and Gc and imposes a requirement on all other smart pointers to provide a wrapper as well.

If RefCell is tough/verbose to use, we may want to revisit how it's architected.

[sfackler]

I wouldn't say it favorites Rc and Gc, it's just that those are the only smart pointers in the standard libraries that require dynamic borrow checking.

How would type improvements help in this case? The new function would have to be implemented manually as opposed to being pulled from Rc at the very least. I'm not totally familiar with the plan for type, though.

[bill-myers]

Just add autoderef and rename RefCell to Mut, and then you'll have an Rc<Mut<T>> that behaves like the RcMut in this issue.

[sfackler]

RefCell was originally called Mut but it was decided to rename it because it was hard to talk about Mut vs mut.

[alexcrichton]

I've been musing recently that we may want to consider renaming Mut to RefCell. I think that RefCell is a bad-enough name and it has common-enough usage that we should use a better name for it.

I'm not too worried about Mut vs mut because these two declarations are quite different:

let x = Mut::new(3);
let mut x = 3;

The first has an explicit ::new where the second one does it, and I think that all introductory examples to rust will not encourage usage of Mut but rather mut. In structs, Mut actually looks quite nice as well:

struct Foo {
    field1: Mut<T>,
    field2: U,
}

It's quite clear that in this case field1 is a mutable field which you then have to understand is dynamically checked.

[sfackler]

I'd be on board with a re-rename. I guess Cell would keep its current name? The discussion that led to the RefCell name is here: #10514 (comment)

cc @pcwalton

[nikomatsakis]

Please move further discussion to the RFCs repo.

[nikomatsakis]

(Closing; please open an issue on the RFCs repo or submit a PR with a concrete proposal to continue the discussion.)