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
{{ message }}
Repository navigation
Does &[!] have a restriction on its length metadata? #620
My understanding is that #510 was a stable guarantee of the validity invariant? So any new requirements would be a breaking change.
(If we are going back on past decisions and making breaking changes, here's another one: we could require that the address part of the pointer plus the length of a T with that metadata can't overflow usize::MAX.)
My understanding is that #510 was a stable guarantee of the validity invariant? So any new requirements would be a breaking change.
#510 on its own is not enough, you also need to know how validity acts behind references. Without #414, &[!] "obviously" must have length 0 or else we have UB due to "reference to invalid value". #414 is not yet on a stable branch. So if we wanted I think we could still extent #413 to also account for uninhabited slice tails.
(If we are going back on past decisions and making breaking changes, here's another one: we could require that the address part of the pointer plus the length of a T with that metadata can't overflow usize::MAX.)
+ For unsized types, this check considers dynamic information from the metadata:
+ If `T` has an unsized tail of slice type (`[U]`), it is inhabited of the length encoded in the metadata is 0 or if `U` is inhabited.
@rust-lang/opsem what do you think, does this make sense?
Ah, good point. I guess we need to phrase this as a condition on being uninhabited instead.
New version:
For unsized types, this check considers dynamic information from the metadata:
In particular, if T has an unsized tail of slice type [U], and if U is uninhabited, and if the length encoded in the metadata is non-zero, then T is uninhabited.
Since I think we effectively left this unresolved in our previous FCP on references to uninhabited types being themselves uninhabited, I propose that for validity of wide references to unsized types, we defined inhabitedness of the unsized tail as follows:
dyn Trait inherits the inhabitedness from the actual underlying type encoded in the metadata. In particular, &dyn Send with a vtable for the ! type is invalid as the pointee type is uninhabited.
[U] is inhabited if U is inhabited or the length metadata is 0. In particular, &[!] requires the length metadata to be 0.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
Activity
RalfJung commentedon Aug 21, 2026
So what would the general rule be? For
&T, ifThas unsized tail[U], and ifUis uninhabited, then the length must be 0?That does seem consistent with the fact that we'd consider
&[!; 0]to be valid but&[!; 1]is insta-UB to create.Jules-Bertholet commentedon Aug 24, 2026
My understanding is that #510 was a stable guarantee of the validity invariant? So any new requirements would be a breaking change.
(If we are going back on past decisions and making breaking changes, here's another one: we could require that the address part of the pointer plus the length of a
Twith that metadata can't overflowusize::MAX.)RalfJung commentedon Aug 24, 2026
#510 on its own is not enough, you also need to know how validity acts behind references. Without #414,
&[!]"obviously" must have length 0 or else we have UB due to "reference to invalid value". #414 is not yet on a stable branch. So if we wanted I think we could still extent #413 to also account for uninhabited slice tails.(Let's take this to Zulip.)
RalfJung commentedon Aug 24, 2026
I have added this to the Reference PR:
@rust-lang/opsem what do you think, does this make sense?
inkreasing commentedon Aug 24, 2026
I think this wording might be confusing if you consider a type like:
Here T has an unsized tail and U = u8 which is inhabited, so T would be inhabited.
RalfJung commentedon Aug 24, 2026
Ah, good point. I guess we need to phrase this as a condition on being uninhabited instead.
New version:
Jules-Bertholet commentedon Aug 24, 2026
That seems to be saying that if any instance of a type
Thas non-zero metadata, then the typeTas a whole is uninhabited.RalfJung commentedon Aug 24, 2026
It's so much easier to write this out in math than in English, why do we bother with this nonsense. :/
I changed it to "the pointee is uninhabited". Technically this is a predicate of "pointee type and metadata" now.
RalfJung commentedon Aug 26, 2026
Since I think we effectively left this unresolved in our previous FCP on references to uninhabited types being themselves uninhabited, I propose that for validity of wide references to unsized types, we defined inhabitedness of the unsized tail as follows:
dyn Traitinherits the inhabitedness from the actual underlying type encoded in the metadata. In particular,&dyn Sendwith a vtable for the!type is invalid as the pointee type is uninhabited.[U]is inhabited ifUis inhabited or the length metadata is 0. In particular,&[!]requires the length metadata to be 0.@rfcbot fcp merge
rust-rfcbot commentedon Aug 26, 2026
@RalfJung has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed.
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
RalfJung commentedon Sep 6, 2026
Looks like we're doing this via joint FCP with t-lang in rust-lang/reference#2337. I'll close this one and carry over the checkmarks.
@rfcbot fcp cancel
rust-rfcbot commentedon Sep 6, 2026
@RalfJung proposal cancelled.