ArcStr

A better reference-counted string type for Rust with zero-cost string literal support

Library
Cargo
v1.2.0
149stars
Apache-2.0 OR MIT OR Zlib

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
38/100Needs Attention
Development Activity0
Maintenance20
Community52
Maturity60
Momentum20

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
73/100Good
Architecture78
Code Quality76
Innovation74
Learning Curve62

ArcStr defines a reference-counted string type intended as a better alternative to Arc<str> or Arc<String> for most use cases. It intentionally drops rarely-used Arc features (like Weak references and Arc::make_mut) in exchange for capabilities that matter more for strings — most notably zero-cost, allocation-free ArcStr instances backed by static data such as string literals.

Written by Thom Chiovoloni, ArcStr is a single-pointer-sized type (good for FFI and cache locality) and, when the default substr feature is enabled, ships a companion Substr type — a (ArcStr, Range<usize>) pair with better ergonomics — representing a cheap, shared slice of a parent ArcStr without copying the underlying data.

What You Get

  • ArcStr — a single-pointer, reference-counted immutable string type usable as a near drop-in replacement for Arc<str>
  • Zero-cost ArcStr construction from &'static str literals — no heap allocation or atomic refcount needed for static data
  • An optional Substr type representing a shared, ranged slice of a parent ArcStr with ergonomic slicing operations
  • no_std compatibility (with an opt-in std feature) for use in embedded or constrained environments
  • Optional Serde support (serde feature) for serializing/deserializing ArcStr values directly

Common Use Cases

  • Sharing immutable string data (identifiers, interned keys, config values) cheaply across many owners without cloning the underlying bytes
  • Storing string literals in data structures without incurring heap allocation, unlike a plain Arc<str> built from a literal
  • Representing substrings of a shared string (e.g. tokens from a parser) via Substr without copying the original text
  • Passing immutable string data across FFI boundaries where a single-pointer representation simplifies the ABI

Under The Hood

Architecture: The crate’s ~2,800 lines of src/ center on arc_str.rs, which implements ArcStr as a single pointer to a heap-allocated header+bytes layout for dynamic strings, but special-cases construction from &'static str to instead store a pointer directly into the static data with a sentinel refcount that skips atomic increment/decrement entirely — this is the source of its ‘zero-cost for literals’ property. substr.rs implements the optional Substr type as an (ArcStr, Range<u32>) pair (using u32 internally for the range to save space, configurable via the substr-usize-indices feature), and impl_serde.rs isolates the optional Serde integration behind a feature flag so it doesn’t affect users who don’t need it. Tech Stack: Only one optional dependency (serde, feature-gated), with loom used as a dev-dependency for exhaustive concurrency model-checking of the atomic refcounting logic under cfg(loom) — a strong signal of care around the crate’s core soundness-sensitive path (manual atomic reference counting). Supports Rust edition 2021 with MSRV 1.57 and no_std via feature flags. Code Quality: The tests/ directory (~800 lines split across arc_str.rs and substr.rs) plus the loom-based concurrency tests give reasonable coverage of both API behavior and the trickier atomic-refcount correctness properties, though the project has seen no commits since mid-2024, making it stable but not under active development. API Design: ArcStr is designed to be usable almost anywhere a &str or Arc<str> would be, implementing the standard string traits (Deref<Target=str>, Display, Hash, comparison traits, etc.), so adopting it typically requires minimal changes to existing string-handling code — the main new concept callers need to learn is the zero-cost-literal behavior and the optional Substr slicing type.

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