You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
Requested by t-types. Useful for type system tests for debugging or simplification.
Investigate relaxing Deref::Target without compiler support
As with any associated type, the default ?Sized bound of Deref::Target cannot be relaxed backwards compatibly:
traitDeref{typeTarget: ?Sized;}fnneeds_metasized<T: ?Sized>(){}fncaller<T:Deref>() -> usize{needs_metasized::<<TasDeref>::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 {
| +++++++++++++++++++++++++++++++++++++
We concluded that this isn't trivially possible and will require deliberate compiler/lang support to happen, discussed below
Split RFC into non-const and const parts so non-const parts can be stabilised sooner
There is sufficient interest in unblocking extern types
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.
Implement only bounds
The language team prefer an "only bounds" syntax for using hierarchies of traits, which needs implemented.
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
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
Update RFC following experienced gained with experimentation and discuss with t-lang
Wait on stabilisation of prerequisites (i.e. const traits)
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 and 2025h2 (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
MetaSizedandPointeeSizedtraits and adds an implicitMetaSizedsupertrait to all traits by defaultPointeeSizedis a "fake" trait which is stripped out during loweringextern type, just not scalable vectors?Sizedcan be rewritten toMetaSizedover an edition boundary and prohibit that syntax if desired#[rustc_no_implicit_bounds](add #![rustc_no_implicit_bounds] #142671)Deref::Targetwithout compiler supportAs with any associated type, the default
?Sizedbound ofDeref::Targetcannot be relaxed backwards compatibly: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,
Derefis particularly tricky because in the limited relaxations in the standard library performed so far (because of the use ofextern typein a couple places), plenty of code that could have beenPointeeSizedended up beingMetaSizedonly because ofDeref.It is not possible to relax
Deref::Targetwithout breaking everything:If this is possible, then revert codegen_llvm: avoid
Derefimpls w/ extern type #137603We concluded that this isn't trivially possible and will require deliberate compiler/lang support to happen, discussed below
extern types?SizedbecomesPointeeSizedin both cases)Movetrait, so collaboration on lcnr's migration plan is expected - we'll implement something along these lines to enable migration to happen.onlyboundsrustfmtconst Sizedandconst MetaSizedand is necessary to unblock scalable vectorsT: const Sizedis the default boundSizedis interpreted asconst SizedSizedboundSizedcould be rewritten toconst Sizedin the next edition and thenSizedwould mean non-const Sizedas expected?Sizedis interpreted asconst MetaSizedconst MetaSizedconst Sizedtypes, that isn't ideal, but those scalable vectors are the only intended use for non-const Sizedwhich are niche and localised, so is tolerableconst SizedHierarchyT: const Sizedbound becomingT: SizedrustfmtUnresolved Questions
Implementation history
type_has_metadata#137601Derefimpls w/ extern type #137603Sizedfast-path #139577match_normalize_trait_ref#140978dyn PointeeSized#143104PointeeSizedis removed during lowering #142652MetaSizedalways holds temporarily #144016PointeeSizedbounds aren't fully validated during HIR ty lowering #142718MetaSizedalways holds temporarily #144016, and pre-requisite to hir_analysis: add missing sizedness bounds #142712Deref::TargetT: !Sizedcandidate to satisfy aT: !MetaSizedobligation. #145537feature(negative_bounds)that meant!Sizedcould prove!MetaSizedDeref::Target#148102Deref::Targetcan be relaxedKnown issues