Bikeshed the name of our NoCell trait

[jswrenn]

Related to #251.

Possibilities:

• Freeze
• NoCell
• InteriorImmutable
• SharedImmutable
• NoInteriorMutability

[jswrenn]

I'm partial to SharedImmutable. It accurately describes that the type is immutable under shared aliasing.

This is advantage over InteriorImmutable and NoInteriorMutability, where the "under shared aliasing" is implicit.

[kupiakos]

I personally find the name Freeze to be incredibly confusing and ambiguous, so I'd really prefer zerocopy (or Rust) not go with that.

Because UnsafeCells are documented as the core requirement for interior mutability, I'm a big fan of NoCell or NoUnsafeCell for being both explicit about the requirement and short. Brevity is more valuable than folks often think, especially when communicating with colleagues. "no cell" is two syllables, the other alternatives are 5+.

immutable under shared aliasing

Not just shared aliasing (being when two &T overlap), but shared borrows generally.

I'm partial to SharedImmutable.

One issue I have with this (and most of these names) is that the constraint is only for the struct itself containing an UnsafeCell, and not for pointers to interior mutable data, e.g. Box<UnsafeCell<T>>. So, an external user might see a trait in zerocopy called SharedImmutable and infer that to mean "the state of this object can never change through a &T", outside the trait's intended purpose. This isn't true because this trait could be implemented for all &T, including &Cell<T>.

Some proposals I've seen put the word "shallow" in to disambiguate, but again that makes the trait name even longer.

[joshlf]

immutable under shared aliasing

Not just shared aliasing (being when two &T overlap), but shared borrows generally.

Can you say more about this distinction? I'm not sure what you're referring to.

I'm partial to SharedImmutable.

One issue I have with this (and most of these names) is that the constraint is only for the struct itself containing an UnsafeCell, and not for pointers to interior mutable data, e.g. Box<UnsafeCell<T>>. So, an external user might see a trait in zerocopy called SharedImmutable and infer that to mean "the state of this object can never change through a &T", outside the trait's intended purpose. This isn't true because this trait could be implemented for all &T, including &Cell<T>.

Some proposals I've seen put the word "shallow" in to disambiguate, but again that makes the trait name even longer.

I agree that this is a problem, although I'll note that NoCell suffers from this as well.

[kupiakos]

I agree that this is a problem, although I'll note that NoCell suffers from this as well.

Agreed, though I'd (weakly) argue it's to a lesser degree. It refers to the presence of a particular struct rather than whether state can be shared-mutated, and I'd suggest that makes it less likely to conflate Cell<T> and &Cell<T>.

I've been thinking about the "shallow" qualifier too, and it has its own problem: shallow could mean "no pointer indirection" or it could mean "is not wrapped in another type". Same with "direct" and "plain".

Some other qualifier ideas:

• NoLocalCell
  • I think this is my favorite? "local" implies non-pointer and doesn't suggest "no wrapper types" in quite the way "shallow" might.
• NoNonPtrCell
• NoCellInLayout
• A coworker suggests NoContainedCell.

Can you say more about this distinction? I'm not sure what you're referring to.

It's (pedantic) pushback on using the term "aliasing" for all &T. Aliasing &T refer to overlapping segments of memory. Two &T bindings are allowed to alias, but can either be aliasing or non-aliasing. While technically you could all say any &T binding is "aliasing" the owning binding by being another way to refer to the same memory, the term loses its utility when used this way - &mut T is then also aliasing.
So, "immutable under shared aliasing" is overly specific: "immutable under shared borrows" or "immutable under shared references" is more correct.