Abstract

This article investigates Rust’s runtime polymorphism by examining the memory layout of dyn Trait objects, wide pointers, and vtables, contrasting them with C++ virtual functions and the Curiously Recurring Template Pattern (CRTP). It highlights Rust's unique handling of Zero-Sized Types (ZSTs), which consume zero bytes in release builds because identity is managed via compile-time ownership rather than runtime memory addresses. Additionally, it details the internal structure of wide pointers—combining separate data and vtable pointers—and explains the constraints governing trait object safety.

Key Points

• Static vs. Dynamic Dispatch: Rust implements compile-time polymorphism through monomorphization (comparable to C++ CRTP), generating specialized function copies with zero runtime cost, whereas dynamic dispatch via dyn Trait enables heterogeneous collections.
• Zero-Sized Types (ZSTs): Empty structs evaluate to 0 bytes (std::mem::size_of) because Rust tracks identity through ownership and the borrow checker at compile time, bypassing the C++ standard mandate requiring every object to occupy at least 1 byte for distinct memory addresses.
• Wide Pointer Architecture: Trait object references (&dyn Trait) span 16 bytes—double the size of standard pointers—comprising an 8-byte data pointer paired with an 8-byte vtable pointer.
• Vtable Generation: Vtables exist as external static data generated per (Type, Trait) pair; a single underlying type implementing multiple traits shares its data pointer across instances while referencing distinct vtable pointers.
• Dyn Compatibility Constraints: Traits must adhere to specific rules to be used dynamically, explicitly prohibiting methods that return Self by value or incorporate generic parameters.

Discussion Highlights

• Terminology Updates: Commenters noted that modern Rust specifications (starting around Rust 1.98.1) have largely replaced the term "Object Safety" with "dyn compatibility".
• Pointer Equality and ZSTs: Participants clarified that Rust defaults to value equality over reference equality, recommending std::ptr::eq for explicit pointer checks and noting that ZSTs lack persistent runtime identities.
• Compiler De-duplication: Discussants highlighted that Rust compilers can de-duplicate identical function implementations, impacting function address uniqueness which can be inspected using std::ptr::fn_addr_eq.
• C++ Comparison Corrections: Commenters challenged the article's premise regarding C++ virtual function returns, pointing out that while C++ permits returning objects by value, doing so introduces risks like object slicing, and noted that Rust handles clone polymorphism via traits like DynClone.
• External Resources: The discussion highlighted community references including cheats.rs for visual memory layouts and an article by ashdnazg on Downcasting Arcs in Rust.