The documentation example about `T: Send` not being required for `Guard::defer_destroy` does not apply to the function

In the docstring for Guard::defer_destroy there is the following passage:

We intentionally didn’t require T: Send, because Rust’s type systems usually cannot prove T: Send for typical use cases. For example, consider the following code snippet, which exemplifies the typical use case of deferring the deallocation of a shared reference:

rust复制

let shared = Owned::new(7i32).into_shared(guard);
guard.defer_destroy(shared); // `Shared` is not `Send`!

It looks like this example was copied from Guard::defer_unchecked, but is not clear to me, how the example is relevant for defer_destroy requiring T: Send or not. Note that the given example does compile and work correctly even if defer_destroy does require T: Send, since i32 is Send and in general T: Send does not depend on Shared<'_, T>: Send.

For the example to make sense, it would need a Shared<T> where T also contains a Shared<U> somewhere, e.g. something like Shared<Shared<i32>>:

let shared = Owned::new(Shared::<i32>::null()).into_shared(guard);
guard.defer_destroy(shared);

But while this example would not compile if T: Shared was required, it seems very contrived to me. Why would we keep a Shared within another Shared for non-contrived reasons? To be clear, I'm not very familiar with this API, so maybe I'm not seeing some important use-cases here. But not requiring T: Send seems like a huge footgun and the documentation doesn't do a very good job of documenting why that footgun is there.