History. Early Rust required all types to possess a statically known size to guarantee stack allocation and efficient value semantics. When dynamically sized types (DSTs) such as slices [T] and trait objects dyn Trait were introduced to support flexible data structures, the language needed a mechanism to distinguish between sized and potentially unsized generic parameters without breaking existing code. The ?Sized syntax was adopted as a "relaxed" bound, allowing generics to explicitly opt out of the default Sized requirement while preserving the ergonomic default for the majority of use cases that do not involve unsized data.
The Problem. The implicit T: **Sized** bound creates a fundamental tension: it enables value manipulation and compile-time memory calculations but prevents functions from accepting dyn Trait or slice types directly without indirection. This restriction forces developers to use Box or references even when ownership semantics are desired, complicating APIs that aim to support both static and dynamic polymorphism. Without ?Sized, generic code cannot abstract over both concrete types and runtime polymorphic objects, leading to either forced heap allocation or duplicated interfaces for sized and unsized variants.
The Solution. The compiler resolves this by enforcing that types bounded by ?Sized can only be accessed through fat pointers—composite values containing a data pointer and runtime metadata (length for slices, vtable for trait objects). When a generic specifies T: **?Sized**, the compiler prohibits operations requiring known sizes, such as std::mem::size_of::<T>() or moving values by value, ensuring all memory layouts remain calculable at compile time. This design allows zero-cost abstractions where sized types use thin pointers and unsized types use fat pointers, with the type system transparently handling the distinction.
A systems monitoring library needed to log errors that could be either small, stack-allocated error codes or large, dynamically formatted error messages implementing dyn **Display**. The initial API design using fn log<T: **Display**>(error: T) rejected trait objects because the implicit Sized bound prevented dyn Display from satisfying the constraint, creating a significant ergonomic hurdle for dynamic error handling.
The first approach considered was mandating Box<dyn **Display**> for all error types, converting even simple u32 error codes into heap allocations. Pros: Unified the API surface and allowed ownership of dynamic errors without complex generics. Cons: Introduced allocator dependencies unsuitable for embedded targets and added measurable latency to hot paths handling simple, static errors.
The second option involved maintaining two separate logging methods: one for generic T: **Display** sized types and one specifically for &dyn **Display**. Pros: Avoided heap allocation for sized types and correctly supported dynamic dispatch for complex errors. Cons: Required significant code duplication, complicated the public API documentation, and forced callers to choose the correct method based on foreknowledge of the type's size.
The team selected a third approach using fn log<T: **?Sized** + **Display**>(error: &T), accepting references to both sized and unsized types. This solution was chosen because it maintained a single, coherent API entry point, supported no-std environments by avoiding mandatory boxing, and imposed zero runtime overhead compared to the dual-method approach. The generic implementation compiled to identical machine code for sized types as the original monomorphic version, while correctly handling trait objects through vtable dispatch.
The resulting crate successfully deployed across microcontrollers and servers, processing millions of heterogeneous error events without allocation overhead. The unified interface allowed developers to pass both &ConcreteError and &dyn Error seamlessly, demonstrating that ?Sized enables truly zero-cost polymorphism across diverse deployment targets.
Why cannot a function return a value of type T where T: **?Sized**?
Functions returning values must place those values in registers or on the stack, requiring a compile-time known size to generate the correct calling convention code and reserve the appropriate stack space. Since ?Sized types like [i32] or dyn **Debug** have runtime-determined sizes, the compiler cannot generate the fixed-size return instruction sequences necessary for the ABI. Only pointer types (Box<T>, &T) have statically known sizes (usize or fat pointer width), making them the sole legal return types for unsized data, fundamentally restricting ?Sized generics to "view" types rather than "value" types that can be moved by value.
How does **?Sized** interact with the coherence rules regarding trait implementations for references?
When implementing traits for &T where T: **?Sized**, the implementation automatically applies to fat pointers (like &[i32] or &dyn Trait) because these are simply references to ?Sized types. Candidates often miss that impl Trait for &T where T: **?Sized** covers both thin and fat pointers, whereas impl Trait for T where T: **Sized** does not. This distinction is crucial for defining blanket implementations that work with both sized data and trait objects, ensuring coherence across the type hierarchy without overlapping implementations that would violate Rust's orphan rules.
What distinguishes the memory representation of **Box<dyn Trait>** from **&dyn Trait** beyond ownership semantics?
While both use fat pointers (pointer + vtable), **Box<dyn Trait>** owns the allocation and stores the vtable pointer specifically for deallocation purposes, whereas **&dyn Trait** merely observes the data. Crucially, Box<T> where T: **?Sized** requires the allocator to handle dynamically sized deallocation using the size stored in the vtable, while references carry no such responsibility. Beginners often overlook that Box enables heap allocation of unsized types that cannot exist on the stack, whereas references simply borrow existing memory, making Box essential for returning owned unsized data from functions.