Tracking Issue for Sized Hierarchy

This is a tracking issue for the experimental implementation of RFC "Hierarchy of Sized traits" (rust-lang/rfcs#3729).
The feature gate for the issue is #![feature(sized_hierarchy)].

Approved by the language team for experimentation on Zulip.

This feature is part of the "Scalable Vectors" project goal from 2025h1, 2025h2 and 2026 (rust-lang/rust-project-goals#270). It was discussed with the language team in the 2024/11/13 design meeting, the 2025/02/05 design meeting, the 2026/03/18 design meeting and the 2026/03/25 design meeting. This feature is currently being worked on by @lqd and @davidtwco.

About tracking issues

Tracking issues are used to record the overall progress of implementation.

They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Discussion comments will get marked as off-topic or deleted. Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

1. Implement non-const parts of RFC (rust-lang/rust#137944)
   • Introduces the MetaSized and PointeeSized traits and adds an implicit MetaSized supertrait to all traits by default
     • PointeeSized is a "fake" trait which is stripped out during lowering
   • There's value in this half of the changes, as it unblocks extern type, just not scalable vectors
   • ?Sized can be rewritten to MetaSized over an edition boundary and prohibit that syntax if desired
2. Add #[rustc_no_implicit_bounds] (rust-lang/rust#142671)
   • Requested by t-types. Useful for type system tests for debugging or simplification.
3. Investigate relaxing Deref::Target without compiler support

   • As with any associated type, the default ?Sized bound of Deref::Target cannot be relaxed backwards compatibly:

     trait Deref {
         type Target: ?Sized;
     }
     
     fn needs_metasized<T: ?Sized>() {}
     fn caller<T: Deref>() -> usize {
         needs_metasized::<<T as Deref>::Target>()
         //~^ error! the trait bound `<T as Deref>::Target: MetaSized` is not satisfied 
     }
     

     This is a known limitation of the proposal and for most use cases of the new sizedness traits is unlikely to be a major issue

     However, Deref is particularly tricky because in the limited relaxations in the standard library performed so far (because of the use of extern type in a couple places), plenty of code that could have been PointeeSized ended up being MetaSized only because of Deref.

   • It is not possible to relax Deref::Target without breaking everything:

     error[E0277]: the size for values of type `<C as Deref>::Target` cannot be known
       --> /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/yoke-0.8.0/src/zero_from.rs:16:42
        |
     16 |     for<'a> <Y as Yokeable<'a>>::Output: ZeroFrom<'a, <C as Deref>::Target>,
        |                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ doesn't have a known size
        |
        = help: the trait `MetaSized` is not implemented for `<C as Deref>::Target`
     note: required by a bound in `ZeroFrom`
       --> /cargo/registry/src/index.crates.io-1949cf8c6b5b557f/zerofrom-0.1.6/src/zero_from.rs:57:25
        |
     57 | pub trait ZeroFrom<'zf, C: ?Sized>: 'zf {
        |                         ^ required by this bound in `ZeroFrom`
     help: consider further restricting the associated type
        |
     41 |     pub fn attach_to_zero_copy_cart(cart: C) -> Self where <C as Deref>::Target: MetaSized {
        |                                                      +++++++++++++++++++++++++++++++++++++
     

   • If this is possible, then revert rust-lang/rust#137603

   • We concluded that this isn't trivially possible and will require deliberate compiler/lang support to happen, discussed below

4. Split RFC into non-const and const parts so non-const parts can be stabilised sooner
   • There is sufficient interest in unblocking extern types
5. Implement migration strategy
   • Associated types and supertraits both require migration in order to achieve the desired default bound (?Sized becomes PointeeSized in both cases)
   • This migration need is shared by those working on the Move trait, so collaboration on lcnr's migration plan is expected - we'll implement something along these lines to enable migration to happen.
6. Implement only bounds
   • The language team prefer an "only bounds" syntax for using hierarchies of traits, which needs implemented.
7. Adjust documentation (see instructions on rustc-dev-guide)
8. Style updates for any new syntax (nightly-style-procedure)
   • Style team decision on new formatting
   • Formatting for new syntax has been added to the Style Guide
   • (non-blocking) Formatting has been implemented in rustfmt
9. Stabilization PR for non-const Sized Hierarchy (see instructions on rustc-dev-guide)
10. Implement const Sized Hierarchy RFC
    • Introduces const Sized and const MetaSized and is necessary to unblock scalable vectors
    • To maintain backwards compatibility:
      • T: const Sized is the default bound
      • Explicitly written Sized is interpreted as const Sized
        • There is no way to write a non-const Sized bound
        • Sized could be rewritten to const Sized in the next edition and then Sized would mean non-const Sized as expected
      • ?Sized is interpreted as const MetaSized
      • Default supertrait is const MetaSized
    • All default bounds would be their strictest possible, making existing code incompatible with non-const Sized types, that isn't ideal, but those scalable vectors are the only intended use for non-const Sized which are niche and localised, so is tolerable
    • Currently blocked waiting on the next solver
      • The only practical way to implement this feature is to have the sizedness traits always be const behind-the-scenes but without the user being able to refer to their constness
      • This requires an a sufficient const traits implementation in both the old and next solvers, and the old solver's implementation is not sufficient
11. Investigate and implement edition migration for const Sized Hierarchy
    • Extend migration strategy for non-const sizedness to handle the default T: const Sized bound becoming T: Sized
12. Update RFC following experienced gained with experimentation and discuss with t-lang
13. Wait on stabilisation of prerequisites (i.e. const traits)
14. Adjust documentation (see instructions on rustc-dev-guide)
15. Style updates for any new syntax (nightly-style-procedure)
    • Style team decision on new formatting
    • Formatting for new syntax has been added to the Style Guide
    • (non-blocking) Formatting has been implemented in rustfmt
16. Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• What names should be used for the traits?

Implementation history

• #137944
  • Initial implementation of the non-const parts of the Sized Hierarchy RFC
  • Approved to be merged by t-types in FCP at https://github.com/rust-lang/rust/pull/137944#issuecomment-2912207485
  • Pre-requisites:
    • #137599
    • #137600
    • #137601
    • #137602
    • #137603
    • #137604
    • #137606
    • #137613
    • #139577
    • #140978
• #142671
  • Follow-up requested by t-types to simplify tests that would benefit from not having any default bounds
• #143104
  • Fix for #142652
• #144016
  • Temporary fix for #143992 while a proper fix is implemented
• #142693
  • Fix for #142718
• #144064
  • Proper fix for #144016, and pre-requisite to #142712
• #142712
  • Fixes elaboration of item bounds on associated types to include sizedness
  • Necessary to be able to experiment with relaxing Deref::Target
• #145537
  • Fixing a bug with feature(negative_bounds) that meant !Sized could prove !MetaSized
• #148102
  • Testing whether Deref::Target can be relaxed

Known issues

• #143830
  • This is known breakage that was accepted by the types team in https://github.com/rust-lang/rust/pull/137944#issuecomment-2912207485
  • It is fixed in the next solver