Pre-RFC: Rename RefCell to give it a descriptive name

#1

I thought I’d start discussion here before writing up a full-blown RFC, in case my brain is at fault.

As the title suggests, I’d like to propose we change the name of RefCell to be more descriptive.

First a summary of RefCell:

  • It provides interior mutability: objects inside can be mutated through an immutable reference. This is safe because:
  • It does borrow checking at run-time.

Now let’s do an analysis of the current name:

  • Ref: short for reference. Most likely refers to the run-time-checked references that the RefCell provides.
  • Cell: refers to the Cell type which supports interior mutability for Copy types. The term is probably used here to connote the “interior mutability” property, rather than the Cell type itself. I’m not sure if the term “Cell” has a precedent outside of Rust.

I feel the current name is kind of poor, as you can see from the complexity of the analysis. If there’s a shorter explanation that I’m missing, please enlighten me. Up until recently, I’ve actually had to keep re-learning what the RefCell type actually does because I haven’t found a need for it yet and its name doesn’t describe its purpose very well. It’s been very much a case of “which one is that again?”.

Here are a few proposals for a new name:

  • RunCheck<T> / RunChecked<T>
  • DynamicCheck<T>
  • Dynamic<T>

My personal preference is RunChecked<T>. So what do you guys think? Is a name change a reasonable proposal? What name do you like best? Answer below!

#2

I do not think the proposed names are better:

RunCheck<T>/RunChecked<T>/DynamicCheck<T> - eh, what are we checking for? Dynamic<T> - eh, what is dynamic? Does this mean dynamic typing? Then what is the <T> doing?

The current name RefCell<T> is fine.

#3

I’ve mostly made my peace with the *Cell names, although it may still be nice to find better ones. Originally there was only the current RefCell and it was called Mut; the renaming happened along with the introduction of Cell, with the additional motivation that Mut was causing confusion with mut especially when spoken. (For what it’s worth, I’m still not sure if I agree with this; I suspect that names of programming language entities are overwhelmingly more often read than heard, but this may be a function of one’s environment.)

In any case I believe the names should be based on capabilities, i.e. what use case is satisfied, rather than mechanism, i.e. how that is accomplished. Cell allows for mutation even in “immutable” (shared) locations. RefCell expands upon this by also allowing the contents to be borrowed (with runtime checks). So I think appropriate names might be along of the lines of Mutable for Cell (resp. UnsafeMutable for UnsafeCell), and BorrowableMutable for RefCell - where of course the latter is immensely awkward and not a serious suggestion. Coming up with a formulation of the latter which captures the same essence without being so awkward is the main challenge.

#4

If you accept Cell as the basic name, RefCell should have a derived name, for example “RWCell” (borrowable just like a multiple readers vs exclusive writer lock) or “DynamicCell”. Ultimately it’s not a very big deal.

#5

I’m really glad you brought this up. I’ve long wanted to rename Cell and RefCell to something more suggestive. In particular, RefCell is in some sense a “sequential” reader/writer lock, while Cell is in some sense a sequential analog to the various Atomic* types.

I’ve never been able to come up with a naming scheme that helpfully reflects this intuition, though.

Another option would be to somehow refer to “interior mutability” in the name.

I’ll give it some more thought, but I’d definitely like to improve these names if we can!

#6

I think that RefCell is actually a nice name. Cell has the right “inside-the-structure-but-not-of-it” feeling, and RefCell implies nicely the ability to take references to its content. The most-similar concepts are locks and atomicity, and I think they are way too associated with multi-threading to be of use here.

Also, typical Rust convention is to name types according to what they are, rather than what they do (see Vec<T>, Box<T>, Rc<T> rather than List<T>, Owned<T>, Shared<T>), and RefCell<T> fits within that pattern.

#7

Nice observation, maybe because structs fundamentally represent something that is, and trait describes the does part.