A reference can be

  • unique
  • not unique, but still exclusive
  • owner or alias
  • mutable or immutable

Let’s think about those properties and their relationships.

Reference Uniqueness

When there is only one reference to a memory location, that reference is the unique reference. It implies it is safe to modify the memory. It also implies it is safe to deallocate it.

For example, Rust ensures every reference is unique before deallocating it.

Reference Exclusivity

An exclusive reference is the only accessible reference to the given memory at one point of execution, even though there may be other inaccessible references to the same memory.

Unique reference implies exclusivity, but not the other way around.

Reference Ownership

Owner references are responsible for deallocating the memory, even if there might be non-owner references to the same memory (aliases). So, uniqueness implies ownership, but not the other way around.

Every owner reference is unique and exclusive at the beginning. But, uniqueness and exclusivity can be temporarily lost due to borrowing.

In the RAII pattern, declared variables are the owner references. But, (unsafe) pointers have no owners designated.

In Rust, there is no way to pass owned references to other functions. The viable alternative is moving objects around. In this sense, ownership is restricted to the declared function in Rust.

Reference Mutability

Mutability implies exclusivity in Rust, but not the other way around.

For example, a local variable can be declared immutable, while it will start out to be a unique, exclusive and owner reference. So, exclusivity doesn’t always mean mutability.

Also, there is a situation where an immutable reference turns out to be the only accessible reference (thus, the exclusive reference). That happens when it’s the only live borrow from a mutable reference. In this case, I argue that it could be allowed to upgrade to a mutable reference under certain conditions.

Summary of the Relationships

  • Uniqueness implies ownership.
  • Ownership implies uniqueness and exclusivity, unless borrowed.
  • Mutability implies exclusivity.
  • Exclusivity implies mutability, unless prohibited.

Conclusion

  • Uniqueness is a state of an owner reference, and it doesn’t seem useful to declare an owner reference to be permanently unique.
  • Ownership should be allowed to be passed around for flexibility. Thus, owner and mutable reference types need to be distinguished in programming languages.
  • While mutability and exclusivity are not exactly the same, it’s unclear whether it’s worth having separate mutable and exclusive reference types in programming languages. Mutable reference type alone may be enough.
  • Immutable references can be exclusive, but they are not allowed to be converted/upgraded to mutable references, even if it’s safe to do so.