Skip to content

ManuallyDrop layout guarantees? #302

Closed

Description

@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?

Activity

  1. thomcc commented on Aug 26, 2021

    @thomcc
    Member

    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.

  2. joshlf commented on Aug 26, 2021

    @joshlf
    Author

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

  3. memoryruins commented on Aug 26, 2021

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

  4. thomcc commented on Aug 27, 2021

    @thomcc
    Member

    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.

  5. joshtriplett commented on Sep 4, 2021

    @joshtriplett
    Member

    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.

  6. joshlf commented on Sep 4, 2021

    @joshlf
    Author

    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 😛

  7. Lokathor commented on Sep 4, 2021

    @Lokathor
    Contributor

    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.

  8. RalfJung commented on Sep 4, 2021

    @RalfJung
    Member

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

  9. added 2 commits that reference this issue on Mar 28, 2022
  10. ChayimFriedman2 commented on May 17, 2022

    @ChayimFriedman2

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions