One of Rust's core promises is that libraries can build abstractions that feel built-in. Rc, Arc, Box — these feel like native language features, not afterthoughts.

But there's a catch. These smart pointers are almost as ergonomic as &T and &mut T. Not quite.

The gap is small, but it's there. And it matters more than you'd think.

The Second-Class Citizen Problem

When you write code with a built-in reference, you get three things for free that custom smart pointers can't easily replicate:

  1. Automatic reborrowing — &(*x).field just works
  2. Field projections — accessing .field through a reference gives you the right type
  3. Safe Pin ergonomics — pinning works naturally with references

Custom smart pointers? They hit walls. You can't implement Deref to return &self.field with the right lifetime. You can't make your smart pointer reborrow like &mut does. You can't participate in patterns that rely on these reference behaviors.

This creates a "second-class citizen" problem. Your custom pointer type might be perfectly sound, but users will hit friction — workarounds, extra annotations, or just giving up and using &T directly.

What "Beyond the &" Aims to Fix

The Rust team has identified three main areas where they want to close the gap:

Reborrow Traits

Right now, reborrowing works because the compiler has special knowledge about & and &mut. When you do:

let mut x = String::from("hello");
let rx = &mut x;
let ry = &mut *rx; // reborrow, rx is suspended

This "just works" because it's baked into the language. Custom smart pointers can't replicate this. The goal is to design a trait system — likely called "reborrow traits" — that lets any smart pointer opt into this behavior.

Field Projections

When you access a field through a reference, Rust knows whether you're getting an immutable or mutable reference, and what the lifetime should be:

struct Inner { value: i32 }
struct Outer { inner: Inner }

fn get_value(o: &Outer) -> &i32 {
    &o.inner.value // Rust knows this lifetime comes from o
}

This works because the compiler tracks field projections for built-in references. For custom smart pointers, there's no way to tell the compiler "when users access fields through my type, here's how to project them."

The "Beyond the &" initiative aims to add a field projections mechanism — possibly through a trait — that lets smart pointer authors define how field access should work through their types.

Pin Ergonomics

Pin exists to support async/await and other use cases where a value shouldn't be moved after initialization. But it interacts awkwardly with custom pointers. The team is exploring improvements to make Pin work more naturally with user-defined types.

Why This Matters

On the surface, this sounds like compiler internals. But the implications are practical:

Cross-language interop. If you're building Rust bindings to C++ or Python, you often need smart pointers that behave like native references. Today, you fight the type system. "Beyond the &" would let you create pointers that feel native to Rust users.

Rust for Linux. The kernel uses custom smart pointers to express particular data structures. Better ergonomics here means cleaner, safer kernel code.

New abstractions. Want a pointer that tracks usage statistics? A pointer that validates access? A pointer with built-in caching? Today, these hit the ergonomic wall. Tomorrow, they could feel as natural as &T.

What's Next

This is a multi-year effort. The 2025H2 goals focused on designing these features — figuring out the right syntax and semantics. Implementation will follow.

The team is experimenting with syntax ideas like @ for custom reborrowing and exploring how field projections could work with the existing type system.

If you want to follow along, the Rust Project Goals page tracks progress. The "Beyond the &" goal has Benno Lossin as the point of contact, with Tyler Mandry from the lang team.

The Bigger Picture

"Beyond the &" represents a shift in how we think about Rust. For years, the story was: "Write unsafe code carefully, then wrap it in a safe API." The next chapter is different: "Build abstractions so powerful that users never need to drop down to unsafe code at all."

The reference types &T and &mut T have been special for too long. It's time to share that power.