stable_deref_trait

An unsafe marker trait identifying types like Box, Rc, and Vec that deref to a stable address

Library
Cargo
v1.2.1
37stars
Apache License 2.0

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
35/100Needs Attention
Development Activity40
Maintenance4
Community24
Maturity60
Momentum12

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
70/100Good
Architecture65
Code Quality70
Innovation55
Learning Curve90

stable_deref_trait defines a single unsafe marker trait, StableDeref, for container types whose dereferenced target address stays fixed even when the container itself is moved. Standard types like Box, Vec, Rc, Arc, and String all implement it, and the crate additionally defines CloneStableDeref for reference-counted types where every clone derefs to the same underlying address.

The trait exists purely as an interoperability contract: crates such as owning_ref and rental rely on StableDeref to soundly build self-referential-style wrappers around a container, and library authors writing their own smart-pointer-like types can implement it so their types work correctly with that ecosystem. It supports no_std and alloc-only builds via Cargo feature flags, making it usable in embedded and other constrained environments.

What You Get

  • The StableDeref unsafe marker trait, implemented out of the box for Box, Vec, Rc, Arc, and String
  • The CloneStableDeref marker trait for reference-counted types where clones deref to the same address
  • A no_std-compatible build via default-features = false, with an optional alloc feature implementing the trait for alloc-crate equivalents
  • Zero runtime dependencies — the entire crate is a single small src/lib.rs defining traits only

Common Use Cases

  • Implementing a custom smart-pointer or Vec-like type that needs to interoperate with owning_ref or rental-style self-referential wrappers
  • Building a no_std or alloc-only crate that still needs to express stable-address guarantees for its container types
  • Declaring, as a library author, that your wrapper type upholds the stable-dereference contract so downstream consumers can build safe abstractions on top of it

Under The Hood

Architecture — The entire crate is a single src/lib.rs defining two marker traits, StableDeref (extends Deref) and CloneStableDeref (extends StableDeref + Clone), plus blanket unsafe impl blocks for Box, Vec, Rc, Arc, and String (and their alloc-crate equivalents under the alloc feature). There is no runtime logic — the crate exists entirely as a compile-time contract between implementors and consumers like owning_ref.

Tech Stack — Pure Rust, 100% of the codebase, with zero external dependencies. Cargo feature flags (std, alloc) control which blanket implementations are compiled, allowing the crate to support no_std targets.

Code Quality — Given the crate’s scope (a marker-trait definition with blanket impls for well-known standard types), there is little surface for bugs; the soundness burden falls on whoever writes an unsafe impl StableDeref for a new type, not on this crate’s own code. There are no automated tests in the repository since there’s no runtime behavior to exercise, which is appropriate for a trait-only crate of this kind, though it does mean correctness for third-party implementors rests on documentation rather than compiler-checked guarantees.

API Design — The API is about as minimal and unsurprising as a Rust crate can be: two traits, clearly named, with a README that explains the contract and gives the exact Cargo.toml snippet needed to opt into no_std/alloc mode. There’s essentially no learning curve beyond understanding why the guarantee matters (self-referential struct safety), which the README explains concisely.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search