ManuallyDrop layout guarantees?

[joshlf]

The docs for ManuallyDrop state:

ManuallyDrop<T> is subject to the same layout optimizations as T.

This hints, but does not explicitly guarantee, that ManuallyDrop<T> has the same layout as T. Do we want to guarantee that?

[thomcc]

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]

Put up a documentation PR. Will wait to move forward with that until the discussion here is resolved.

[memoryruins]

@thomcc

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).

[thomcc]

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.

[joshtriplett]

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.

[joshlf]

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]

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]

We really need some procedure by which to declare a libstd repr(transparent) as an explicit stable guarantee...

[ChayimFriedman2]

I guess this should be closed? rust-lang/rust#88375 is merged by now.