Skip returning closure from from into_inner()

[tormol]

Defuse is a really good word to describe its purpose! I had considered unguard or dismiss for a function that only returns the value, but decided into_inner was the least confusing.

Currently into_inner() triggers the wrong_self_convention clippy lint, but that gotta be a false positive and not worth disabling (clippy:: tool attributes requires a much more recent Rust version).

[bluss]

Can't we just invert the order of the drop and then we don't need the extra manually drop?

[bluss]

Hm ok maybe I'd instead read both vars like before and let the closure drop. It doesn't need to be more complex I think

[tormol]

While only changing the return line would work, I don't like how correctness would then rely on the exact placement of the implicit drop. It would also need comments to explain that the closure must be read and assigned to a local variable. The new code makes that drop explicit.

[bluss]

The diff would be like this:

     #[inline]
-    pub fn into_inner(guard: Self) -> (T, F) {
+    pub fn into_inner(guard: Self) -> T {
         // Cannot pattern match out of Drop-implementing types, so
         // ptr::read the types to return and forget the source.
         unsafe {
             let value = ptr::read(&*guard.value);
             let dropfn = ptr::read(&*guard.dropfn);
             mem::forget(guard);
-            (value, dropfn)
+            value
         }
     }
 }

it looks like the simplest solution to me.

[tormol]

Yes, but then it's tempting to later remove let _dropfn = ptr::read(&*guard.dropfn); or change it to let _ = ptr::read(&*guard.dropfn);

[bluss]

Doesn't warrant complicating the function to that degree. Implicit drops are deterministic and happen in every Rust scope, so we know them well. You can insert drop(dropfn) if it needs to be emphasized

[tormol]

OK

[tormol]

I apparently forgot to actually add the changes when I amended yesterday 😄

Pushed now.

[bluss]

Thanks!