Rust’s only bounds could reshape type sizing in the language

Rust’s sizing story is getting a lot less binary, and that is exactly why it matters. The new work around only bounds and the Sized hierarchy is trying to give the compiler a more precise way to talk about values whose size is not simply known or unknown, but known in different ways depending on the type. That shift could change how you design generics, trait bounds, and low-level abstractions long before any of it feels mainstream.

Why the old Sized split is running out of road

Rust’s current model is easy to remember and, most of the time, easy to use: type parameters default to Sized, and ?Sized is the escape hatch when you need to work with dynamically sized types. The Reference still describes DSTs as values whose size is only known at runtime, with slices, trait objects, and str as the familiar examples, and it notes that generic parameters and associated types get Sized by default unless relaxed with ?Sized. That has been good enough for the classic unsized cases, but it is also the source of the friction this proposal is trying to remove.

The snag is that Rust is now running into types that do not fit neatly into either bucket. Extern types are a good example, because they have no size in the ordinary sense, while Arm’s scalable vectors can have a size that is known at runtime but not at compile time. The Rust Project Goals page says the Sized hierarchy work exists specifically to let Rust express types that are neither Sized nor ?Sized, and the project-goals entry says the effort builds on RFC 3729 and RFC 3838.

What the new hierarchy is actually measuring

This is where the discussion gets more interesting than “unsized or not.” The proposal is not just asking whether a type is dynamically sized, but whether its size can be determined from pointer metadata, whether all values of the type share the same runtime size, and how the compiler should model that metadata at all. That is why the design sketches a richer hierarchy, with categories such as MetaSized and PointeeSized rather than forcing every case through the old Sized versus ?Sized split.

The nightly docs already show that shift in embryo. Sized now sits on top of MetaSized, which is described as types whose size can be determined from pointer metadata, while PointeeSized is the broader marker for types that may or may not have a size. In the pointer metadata docs, Rust also spells out the mechanism that makes this distinction useful: raw and reference pointers are made of a data pointer plus metadata, with thin pointers for Sized types and extern types, and wide pointers for DSTs such as slices, trait objects, and str.

That sounds abstract until you translate it into library design. If the language can distinguish “has a known compile-time size,” “has a runtime size recoverable from metadata,” and “may not have a meaningful size at all,” then generic APIs can stop pretending those cases are interchangeable. The likely payoff is more precise trait bounds, fewer awkward special cases around associated types and pointer-like abstractions, and a better foundation for future portable SIMD work. That last point is an inference, but it follows directly from the way the project goals frame the work and from how the metadata model is already exposed in nightly.

How the feature is being staged

This is not a paper design sitting in a vacuum. The experimental feature is tracked in rust-lang/rust issue 144404, gated behind `#![feature(sized_hierarchy)]`, and explicitly described in the Unstable Book as introducing a hierarchy of Sized traits. The tracking issue says the experimental implementation was approved by the language team for experimentation on Zulip, is being worked on by lqd and davidtwco, and has already had design meetings on 2024/11/13, 2025/02/05, 2026/03/18, and 2026/03/25.

The project-goals material also makes clear that this is being phased in rather than dumped into the language all at once. One 2026 goal page says the non-const part is being prioritized so Rust can get value sooner, while the const Sized portion is deferred to a future goal because it depends on progress in const traits. That sequencing matters: the hierarchy itself can unlock extern types first, while the more ambitious const-related pieces wait for the trait solver and const machinery to catch up.

Why the ecosystem is already paying attention

This may feel niche, but the surrounding conversation says otherwise. LWN described RFC 3729 as introducing a finer-grained hierarchy of size traits, precisely because the old two-category model is too coarse for some newer proposals. Rust Internals has also been discussing exotically sized types for years, including scalable vectors, which is a good reminder that language design in Rust often begins as a compiler corner case and only later reveals itself as a library ergonomics problem.

The project-goals entry goes even further and says the SVE and SME owners had a nearly complete RFC and had already discussed it informally with language and compiler team members before the goal was submitted. That is the real signal here: the idea has moved past “interesting type-system thought experiment” and into Rust’s formal implementation pipeline, but it is still experimental enough that the compiler team is using nightly markers, tracking issues, and design meetings to shape the result.

The big takeaway is simple enough to fit on a whiteboard: once Rust stops treating Sized as an all-or-nothing assumption, more APIs become describable without contortions. That does not just help the compiler understand exotic types a little better. It gives the language a vocabulary that matches the hardware, the metadata model, and the kinds of generic abstractions Rust keeps growing into.