library: core: document layout guarantee of TypeId by dakr · Pull Request #148265 · rust-lang/rust (original) (raw)
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Status: Awaiting review from the assignee but also interested parties.
Relevant to the library team, which will review and decide on the PR/issue.
labels
This change is insta-stable, or significant enough to need a team FCP to proceed.
label
Relevant to the library API team, which will review and decide on the PR/issue.
Relevant to the compiler team, which will review and decide on the PR/issue.
Nominated for discussion during a libs-api team meeting.
Nominated for discussion during a compiler team meeting.
and removed T-libs
Relevant to the library team, which will review and decide on the PR/issue.
labels
19 tasks
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
…uarantees, r=scottmcm
Make explicit that TypeId's layout and size are unstable
Or worded differently, explicitly remark non-stable-guarantee of TypeId layout and size.
This PR makes no additional guarantees or non-guarantees, it only emphasizes that TypeId's size and layout are unstable like any other #[repr(Rust)] types.
This was discussed during #t-compiler/meetings > &rust-lang#91;weekly&rust-lang#93; 2025-10-30 @ 💬, where the compiler team discussed a request rust-lang#148265 to have the standard library (and language) commit to TypeId guaranteeing a size upper bound of 16 bytes. In the meeting, the consensus was:
- We were sympathetic to the use case discussed in the request PR, however we feel like this stability guarantee is premature, given that there are unresolved questions surrounding the intended purpose of
TypeId, and concerns surrounding its collision-resistance properties rust-lang#10389 and rust-lang#129014. We would prefer not making any of such guarantee until the collision-resistance concerns are resolved. - Committing to a stability guarantee on the size upper bound now would close the door to making
TypeIdlarger (even if unlikely for perf reasons).
Given that we have previously broken people who asserted the size of TypeId is 8 bytes, it was also discussed in the meeting that we should explicitly note that the size and layout of TypeId is not a stable guarantee, and is subject to changes between Rust releases, and thus cannot be relied upon -- if breakage in people's code is due to that assumption, it will be considered a won't-fix.
- So even if
#[repr(Rust)]types have unstable size and layout, this PR makes it explicit forTypeIdsince this type can feel "special" and users can be lead into thinking its size and layout is something they can rely upon.
r? @scottmcm (or libs/libs-api/lang)
rust-timer added a commit that referenced this pull request
Rollup merge of #148394 - jieyouxu:remark-typeid-no-layout-guarantees, r=scottmcm
Make explicit that TypeId's layout and size are unstable
Or worded differently, explicitly remark non-stable-guarantee of TypeId layout and size.
This PR makes no additional guarantees or non-guarantees, it only emphasizes that TypeId's size and layout are unstable like any other #[repr(Rust)] types.
This was discussed during #t-compiler/meetings > [weekly] 2025-10-30 @ 💬, where the compiler team discussed a request #148265 to have the standard library (and language) commit to TypeId guaranteeing a size upper bound of 16 bytes. In the meeting, the consensus was:
- We were sympathetic to the use case discussed in the request PR, however we feel like this stability guarantee is premature, given that there are unresolved questions surrounding the intended purpose of
TypeId, and concerns surrounding its collision-resistance properties #10389 and #129014. We would prefer not making any of such guarantee until the collision-resistance concerns are resolved. - Committing to a stability guarantee on the size upper bound now would close the door to making
TypeIdlarger (even if unlikely for perf reasons).
Given that we have previously broken people who asserted the size of TypeId is 8 bytes, it was also discussed in the meeting that we should explicitly note that the size and layout of TypeId is not a stable guarantee, and is subject to changes between Rust releases, and thus cannot be relied upon -- if breakage in people's code is due to that assumption, it will be considered a won't-fix.
- So even if
#[repr(Rust)]types have unstable size and layout, this PR makes it explicit forTypeIdsince this type can feel "special" and users can be lead into thinking its size and layout is something they can rely upon.
r? @scottmcm (or libs/libs-api/lang)
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request
…, r=scottmcm
Make explicit that TypeId's layout and size are unstable
Or worded differently, explicitly remark non-stable-guarantee of TypeId layout and size.
This PR makes no additional guarantees or non-guarantees, it only emphasizes that TypeId's size and layout are unstable like any other #[repr(Rust)] types.
This was discussed during #t-compiler/meetings > [weekly] 2025-10-30 @ 💬, where the compiler team discussed a request rust-lang/rust#148265 to have the standard library (and language) commit to TypeId guaranteeing a size upper bound of 16 bytes. In the meeting, the consensus was:
- We were sympathetic to the use case discussed in the request PR, however we feel like this stability guarantee is premature, given that there are unresolved questions surrounding the intended purpose of
TypeId, and concerns surrounding its collision-resistance properties rust-lang/rust#10389 and rust-lang/rust#129014. We would prefer not making any of such guarantee until the collision-resistance concerns are resolved. - Committing to a stability guarantee on the size upper bound now would close the door to making
TypeIdlarger (even if unlikely for perf reasons).
Given that we have previously broken people who asserted the size of TypeId is 8 bytes, it was also discussed in the meeting that we should explicitly note that the size and layout of TypeId is not a stable guarantee, and is subject to changes between Rust releases, and thus cannot be relied upon -- if breakage in people's code is due to that assumption, it will be considered a won't-fix.
- So even if
#[repr(Rust)]types have unstable size and layout, this PR makes it explicit forTypeIdsince this type can feel "special" and users can be lead into thinking its size and layout is something they can rely upon.
r? @scottmcm (or libs/libs-api/lang)
github-actions bot pushed a commit to model-checking/verify-rust-std that referenced this pull request
…uarantees, r=scottmcm
Make explicit that TypeId's layout and size are unstable
Or worded differently, explicitly remark non-stable-guarantee of TypeId layout and size.
This PR makes no additional guarantees or non-guarantees, it only emphasizes that TypeId's size and layout are unstable like any other #[repr(Rust)] types.
This was discussed during #t-compiler/meetings > [weekly] 2025-10-30 @ 💬, where the compiler team discussed a request rust-lang#148265 to have the standard library (and language) commit to TypeId guaranteeing a size upper bound of 16 bytes. In the meeting, the consensus was:
- We were sympathetic to the use case discussed in the request PR, however we feel like this stability guarantee is premature, given that there are unresolved questions surrounding the intended purpose of
TypeId, and concerns surrounding its collision-resistance properties rust-lang#10389 and rust-lang#129014. We would prefer not making any of such guarantee until the collision-resistance concerns are resolved. - Committing to a stability guarantee on the size upper bound now would close the door to making
TypeIdlarger (even if unlikely for perf reasons).
Given that we have previously broken people who asserted the size of TypeId is 8 bytes, it was also discussed in the meeting that we should explicitly note that the size and layout of TypeId is not a stable guarantee, and is subject to changes between Rust releases, and thus cannot be relied upon -- if breakage in people's code is due to that assumption, it will be considered a won't-fix.
- So even if
#[repr(Rust)]types have unstable size and layout, this PR makes it explicit forTypeIdsince this type can feel "special" and users can be lead into thinking its size and layout is something they can rely upon.
r? @scottmcm (or libs/libs-api/lang)