Questioning the ergonomics and terminology of str as a DST from a memory-model perspective

Hello everyone,

While analyzing the memory layout and semantics of Rust’s string types down to the hardware and register level, I have been reflecting on the architectural design choices around str and DSTs in general. I would appreciate some insights into the underlying rationale and history.

---

1. Terminology: “Dynamically Sized Type”

In low-level systems programming, the word “dynamic” typically denotes runtime type resolution, dynamic dispatch, or late binding. Labeling str as a Dynamically Sized Type (DST) often introduces cognitive friction.

At its core, isn’t str simply an Unsized Type at compile time? Is there a historical or formal type-theoretic rationale why the terminology “Dynamically Sized” was favored over strictly referring to them as “Unsized Types”?

---

2. Architectural Reality of Naked str

From an assembly and machine architecture point of view, an unsized str cannot exist on the stack as a materialized value. It cannot be bound directly (let x: str), passed by value, or manipulated without an indirection/fat pointer:

• &str (16-byte fat pointer on 64-bit architectures: pointer + length)
• Box<str> or Rc<str>

I understand the orthogonal symmetry here: treating str, [T], and dyn Trait uniformly under a single DST framework. However, since a naked str cannot have an independent hardware existence without a fat pointer wrapper, does exposing it as a distinct first-class type at the language level introduce more ergonomic overhead than architectural necessity?

---

3. Ergonomic Surface Area vs. Orthogonality

In practical codebases, this orthogonal design produces a broad spectrum of string representations:

str, &str, String, &String, Box<str>, Cow<str>, along with trait bounds like AsRef<str> vs Borrow<str>.

While the mathematical symmetry of unifying slices and trait objects under one DST mechanism is conceptually elegant, it comes with non-trivial ergonomic surface area.

---

Questions for the Community:

1. Beyond sharing methods across smart pointers (&str, Box<str>, Arc<str>) via Deref, what were the primary design considerations during the early DST RFCs that favored keeping str as a distinct unsized type rather than an intrinsically bundled fat-pointer slice handle?
2. Are there compiler-internal code generation or layout optimization benefits that strictly depend on this separation?

Looking forward to reading your insights and historical context. Thank you!

---

1 post - 1 participant

Read full topic