Skip to content

Tracking Issue for const ptr::drop_in_place #109342

Open

Description

@fee1-dead

Feature gate: #![feature(const_drop_in_place)]

This is a tracking issue for using drop_in_place in const contexts

Public API

// core::ptr

pub const unsafe fn drop_in_place<T: ?Sized + ~const Destruct>(to_drop: *mut T);

Steps / History

Unresolved Questions

  • Confirm that things such as dyn Trait works with this as well

Footnotes

  1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

Activity

  1. added
    T-libs-api[DEPRECATED; DO NOT USE]
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on Mar 19, 2023
  2. juntyr commented on Mar 19, 2023

    @juntyr
    Contributor

    @fee1-dead The summary seems to link a different implementation PR Upon rereading the PR, I saw you also constified drop_in_place there - perhaps the PR title could reflect this?

  3. added a commit that references this issue on Oct 14, 2025
  4. added a commit that references this issue on Oct 14, 2025
  5. added 2 commits that reference this issue on Oct 14, 2025
  6. added a commit that references this issue on Oct 15, 2025
  7. clarfonthey commented on Oct 15, 2025

    @clarfonthey
    Contributor

    With #146187 merged, the description should be updated to include the following functions added to this list:

    • core::ptr::drop_in_place
    • core::mem::ManuallyDrop::drop
    • core::mem::MaybeUninit::assume_init_drop
    • <[core::mem::MaybeUninit<_>]>::assume_init_drop
    • <*mut _>::drop_in_place
    • core::ptr::NonNull::drop_in_place

    All of them are effectively wrappers over drop_in_place, so, they made sense to include in this feature flag. They also all depend on const_destruct (#133214) so that should be marked as a blocker for this as well.

  8. theemathas commented on Oct 15, 2025

    @theemathas
    Contributor

    Currently, drop_in_place can be called on statics in consteval, which feels a bit odd to me. See #146187 (comment)

  9. clarfonthey commented on Oct 15, 2025

    @clarfonthey
    Contributor

    It probably makes more sense to file a separate issue for that now that this feature has been implemented again. Generally, tracking issues are just for listing blockers to stabilisation, not for elaborating on specific ones, which should each have dedicated issues.

  10. added a commit that references this issue on Nov 30, 2025
  11. added
    T-libsRelevant to the library team, which will review and decide on the PR/issue.
    and removed
    T-libs-api[DEPRECATED; DO NOT USE]
    on Aug 12, 2026
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

    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libsRelevant to the library team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions