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 once reference to a memory, that reference is the unique reference. It implies it is safe to modify the memory. Also, it 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 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. By the way, 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.


  • Uniqueness is a state of owner reference and it doesn’t seem to be useful to declare an owner reference to be unique permanantly.
  • 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.

Previous Post
Inferred Mutability: A Cure for Rust’s Mutability Madness
Next Post
Inferred Mutability: Safety Proof of Mutability Upgrade