Tracking Issue for `core::mem::DropGuard`

[yoshuawuyts]

Feature gate: #![feature(drop_guard)]

This is a tracking issue for the core::mem::DropGuard API: a helper type that makes it easy to create impl Drop destructors inline.

Public API

#![feature(drop_guard)]

use std::mem::DropGuard;

{
    // Create a new guard around a string that will
    // print its value when dropped.
    let s = String::from("Chashu likes tuna");
    let mut s = DropGuard::new(s, |s| println!("{s}"));

    // Modify the string contained in the guard.
    s.push_str("!!!");

    // The guard will be dropped here, printing:
    // "Chashu likes tuna!!!"
}

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• ACP: ACP: Add core::mem::WithDrop to associate a custom drop fn with some data libs-team#622
• Implementation: Add core::mem::DropGuard #144236
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• What should the name of the type be? DropGuard, WithDrop and Dropper were some of the preferred options raised in the 2025-07-22 T-Libs-API call.
• Should the impl have a Clone impl? This can always be added in the future, but should be discussed further prior to stabilization.
• Should the Debug impl be transparent? This can always be added in the future, but should be discussed further prior to stabilization.
• What should the name of the method be for "take ownership of the value without running the destructor"? The name current name for this method is into_inner, but other names have been proposed, including: disarm, defuse, disable, and skip_drop.

Footnotes

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

[RalfJung]

Another open question: what should into_inner be called? disarm might be a more evocative name.

[yoshuawuyts]

I've added it as an open question, and listed some of the other options people have brought up as well.

I should add however that I personally dislike any names that evoke imagery of weapons and violence. If we can at all avoid that, I think we should.

[RalfJung]

That is fair. I just think that into_inner has the significant downside of being a very common method name, so one could easily think one sees a call to something else -- or one could refactor code to change the type, and the into_inner may keep working while changing its meaning. I am fine with basically an name that's not a common method name found on many types. :)

[yoshuawuyts]

Yeah I agree: into_inner is a fairly inconspicuous name for an operation that is often load-bearing. Having something that more clearly calls attention to itself seems like it might be worth it.

[FeldrinH]

I just think that into_inner has the significant downside of being a very common method name, so one could easily think one sees a call to something else -- or one could refactor code to change the type, and the into_inner may keep working while changing its meaning.

I don't think this is a problem in practice. DropGaurd::into_inner is an associated function, not a method, so you have to call it as DropGuard::into_inner(value), which makes it quite hard to confuse it for some other into_inner function and also makes it a compile error to pass a value of a different type.

[FeldrinH]

FWIW I like the name into_inner. It is consistent with the existing scopeguard crate and also consistent with analogous methods on other types that affect drop behavior like ManuallyDrop and MaybeUninit.

[riking]

I think the documentation on into_inner should also have an example of calling mem::forget(guard.into_inner()) since mem::forget is mentioned in the prose.