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
That line, and the fact that its #[repr(transparent)] (and documented as such), probably does guarantee this. But yeah, its probably worth being clear about.
and the fact that its #[repr(transparent)] (and documented as such)
rustdoc documents the repr whether or not the library guarantees what its private field contains, which sometimes leads to users assuming too much about the inner private field (e.g. rust-lang/rust#72841 (review)). I agree it would be good to clarify this for ManuallyDrop in the docs (and wonder if any other types in std could benefit from clarification).
which sometimes leads to users assuming too much about the inner private field
In this case, it's very clear that the inner field is a T.
But either way, I think this has been de-facto guaranteed for a while now. It changing would break a lot of existing code, and seems like it was always the intent, so we should guarantee it.
This seems right to me as well; repr(transparent) needs to guarantee this, and the fact that ManuallyDrop is repr(transparent) seems like a very public and required part of ManuallyDrop's ABI that we cannot and should not change.
Activity
thomcc commentedon Aug 26, 2021
That line, and the fact that its
#[repr(transparent)](and documented as such), probably does guarantee this. But yeah, its probably worth being clear about.joshlf commentedon Aug 26, 2021
Put up a documentation PR. Will wait to move forward with that until the discussion here is resolved.
memoryruins commentedon Aug 26, 2021
@thomcc
rustdoc documents the repr whether or not the library guarantees what its private field contains, which sometimes leads to users assuming too much about the inner private field (e.g. rust-lang/rust#72841 (review)). I agree it would be good to clarify this for ManuallyDrop in the docs (and wonder if any other types in std could benefit from clarification).
thomcc commentedon Aug 27, 2021
In this case, it's very clear that the inner field is a
T.But either way, I think this has been de-facto guaranteed for a while now. It changing would break a lot of existing code, and seems like it was always the intent, so we should guarantee it.
joshtriplett commentedon Sep 4, 2021
This seems right to me as well;
repr(transparent)needs to guarantee this, and the fact thatManuallyDropisrepr(transparent)seems like a very public and required part ofManuallyDrop's ABI that we cannot and should not change.joshlf commentedon Sep 4, 2021
Is there a path forward to this becoming an official position of the UCG WG? Not sure what the rules of parliamentary procedure are for the WG 😛
Lokathor commentedon Sep 4, 2021
Nothing anywhere in this repo is official.
The intended path is that when something is ready to be official then it should just go though the RFC process.
RalfJung commentedon Sep 4, 2021
We really need some procedure by which to declare a libstd
repr(transparent)as an explicit stable guarantee...Rollup merge of rust-lang#88375 - joshlf:patch-3, r=dtolnay
Rollup merge of rust-lang#88375 - joshlf:patch-3, r=dtolnay
ChayimFriedman2 commentedon May 17, 2022
I guess this should be closed? rust-lang/rust#88375 is merged by now.