Add std::mem::defer for conveniently build DropGuard<(), FnOnce(())>

[tisonkun]

This refers to #144426.

cc @andylokandy @jplatte

Updated with:

/// Create a new instance of `DropGuard` with a cleanup closure.
///
/// # Example
///
/// ```rust
/// # #![allow(unused)]
/// #![feature(drop_guard)]
///
/// use std::mem::defer;
///
/// let _guard = defer! { println!("Goodbye, world!") };
/// ```
#[unstable(feature = "drop_guard", issue = "144426")]
pub macro defer($($t:tt)*) {
    $crate::mem::DropGuard::new((), |()| { $($t)* })
}

---

Unfortunately, it's hard to convert impl FnOnce() to the input type param F: FnOnce(T) where T = ().

I tried:

impl<F> DropGuard<(), F>
where
    F: FnOnce(()),
{
    pub const fn new<G: FnOnce()>(f: G) -> Self {
        let f = move |()| f();
        Self { inner: ManuallyDrop::new(()), f: ManuallyDrop::new(f) }
    }
}

But it failed because the new closure has a different type of F.

[rustbot]

r? @scottmcm

rustbot has assigned @scottmcm.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[tisonkun]

Suggested change

	/// let _guard = DropGuard::new(|()| println!("Goodbye, world!"));
	/// let _guard = DropGuard::new(|| println!("Goodbye, world!"));

It's more proper to write || without (). But it seems quite hard to fine-tune the type parameter F: FnOnce(T) even if we are sure that T = (). impl FnOnce(()) is different from impl FnOnce().

[nxsaken]

I think the proposed API would be nice to have if it got rid of the unit argument, but as it is it feels like a half-measure.

I don't know if it would be popular, but maybe we could provide a defer! { ... } macro like the scopeguard crate does:

macro_rules! defer {
    ($($t:tt)*) => {
        let _guard = DropGuard::new((), |()| { $($t)* });
    };
}

This works too:

const fn defer<F: FnOnce()>(f: F) -> DropGuard<(), impl FnOnce(())> {
    DropGuard {
        inner: ManuallyDrop::new(()),
        f: ManuallyDrop::new(move |()| f()),
    }
}

[tisonkun]

const fn defer

This looks like a good solution. Let me try it out.

So far we export DropGuard as core::mem::DropGuard. A mem level core::mem::defer/core::mem::guard may be too generic, though.

[tisonkun]

Updated with:

// core::mem::defer
pub const fn defer(f: impl FnOnce()) -> DropGuard<(), impl FnOnce(())> { }
// core::mem::guard
pub const fn guard<T, F>(value: T, f: F) -> DropGuard<T, F> { }

Maybe we should keep DropGuard::new and remove guard. But anyway the functionality is here and now we can consider the naming and API :|

[nxsaken]

I think we should keep DropGuard::new, and that defer should be a macro if it exists. Returning DropGuard<(), impl FnOnce(())> makes the guard's type unnameable and impossible to store in a struct, which seems too limiting for the standard library.

The macro is not perfect, e.g. I don't think you can have both defer! { foo() } and defer!(foo). Also, scopeguard's version of defer binds the guard to an unused variable. This guarantees that defer does what it says, but doesn't allow users to dismiss the guard. We could just return the guard and rely on #[must_use].

[tisonkun]

@nxsaken Great suggestion! Updated.

[tisonkun]

Not sure if |()| { ... } can proper move value when needed.

Added defer_moved_value test case and it seems to work properly.

[tisonkun]

r? libs-api

[andylokandy]

I'd lean toward keeping defer as a function rather than a macro. Macros tend to be heavier in terms of complexity — for example, they don't play as nicely with formatters like rustfmt, and they can be harder to debug or reason about compared to plain functions.

If we go with a macro, one advantage of a macro is that it can wrap the entire let _guard = DropGuard:: new((), |()| { ... }); pattern, which isn't possible with a function. However, if we take this route, we should make sure the design aligns with Rust's general philosophy for standard library macros.

[jplatte]

I think the macro makes a lot of sense, if it includes the let _guard part. That would make it impossible to misuse even if the user disabled unused-must-use, and it's also a decent amount shorter than any other version of this.

Any usage pattern where the lifetime of the guards ends early in some branch via drop (or equivalent) instead of at the end of the scope seems very niche in comparison and IMHO should be fine with DropGuard::new, or some custom locally-defined free function for creating the guard.

[tisonkun]

5 out of 10 in my use cases need to store the DropGuard::new((), |()| { .. }) into a field to hold it during the app lifetime.