Iterator without referencing stack-allocated variable - iter_owned?

[SuperFluffy]

How do you feel about providing a "owned" iterator that takes ownership of the mutation guard rather than a reference? Here's a very quick draft I threw together: SuperFluffy#1 (using OwnedGuard, which is likely not necessary and could be relaxed to G: Guard); it requires a lot of near-duplicate code however.

For context, I am wrapping a papaya::HashMap and want to provide an iterator over it, but papaya is leaking through because of its pin mechanism; take this example:

struct BlobStorage {
    inner: papaya::HashMap<Uuid, Arc<Blob>>,
}

impl BlobStorage {
    fn iter(&self) -> impl Iterator<Item = (&Uuid, &Arc<Blob>)> {
        let pinned = self.pin();
        pinned.iter()
    }
}

/* error
error[E0515]: cannot return value referencing local variable `pinned`
  --> the_example/src/example.rs
   |
77 |         pinned.iter()
   |         ------^^^^^^^
   |         |
   |         returns a value referencing data owned by the current function
   |         `pinned` is borrowed here
   |
   = help: use `.collect()` to allocate the iterator
*./

Example API from the link above:

impl<K, V, S> HashMap<K, V, S>
where
    K: Hash + Eq,
    S: BuildHasher,
{
    #[inline]
    pub fn iter_owned<'g>(&'g self, guard: OwnedGuard<'g>) -> IterOwned<'g, K, V> {
        IterOwned {
            raw: self.raw.iter_owned(self.raw.verify_owned(guard)),
        }
    }
}

[ibraheemdev]

The problem is that the lifetime of items would be tied to the iterator itself, which the standard Iterator trait does not support. The easy way out of this is encoding the stack-allocated guard into your own types. The other way would be an iterator that returns a wrapper around the keys/values (#6) that holds a cloned guard (this would only work for local guards), but I'm not sure if that's worth it.