Description
Proposal
Problem statement
When working with (structurally) pinned ManuallyDrop, the user has to write some unsafe code that is safe (partially) because of certain guarantees ManuallyDrop provides, but for which ManuallyDrop currently doesn't provide safe(r) interfaces.
Motivating examples or use cases
A good example would be the Instrumented struct in tracing. Its inner structurally pinned future is contained as ManuallyDrop, so dropping it can be instrumented as well.
This is how said pinned dropping is implemented: unsafe { ManuallyDrop::drop(this.project().inner.get_unchecked_mut()) }. Its safety is partially guaranteed by how ManuallyDrop::drop works and therefore could be provided by a safer ManuallyDrop interface.
Furthermore, the value inside the pinned ManuallyDrop is accessed via unsafe { self.inner.map_unchecked_mut(|v| &mut **v) (and a corresponding variant without mut). Its safety is guaranteed by ManuallyDrop itself (basically, because it structurally pins its content) and therefore could be provided by a safe ManualDrop interface.
Solution sketch
I propose to add the following interfaces:
impl<T> ManuallyDrop<T> {
fn pinned_deref_mut(pinned: Pin<&mut ManuallyDrop<T>>) -> Pin<&mut T> {
unsafe { pinned.map_unchecked_mut(|manually_drop| manually_drop.deref_mut()) }
}
fn pinned_deref(pinned: Pin<&ManuallyDrop<T>>) -> Pin<&T> {
unsafe { pinned.map_unchecked(|manually_drop| manually_drop.deref()) }
}
}
impl<T: ?Sized> ManuallyDrop<T> {
pub unsafe fn pinned_drop(pinned: Pin<&mut ManuallyDrop<T>>) {
unsafe { Self::drop(pinned.get_unchecked_mut()) }
}
}
The safety requirements for ManuallyDrop::pinned_drop would be the same as for ManuallyDrop::drop. The wording needs to be adjusted a bit, because currently, it says that this function should be called only once, but when adding this, it should say that only one dropping function should be called, and both count as dropping functions, or something similar.
Alternatives
As shown above, it's currently possible to express all these things, but it requires (more) unsafety at the user side. One possibility would be to not change anything and require this unsafety duplication from the user.
It should be noted that it would be quite easy to write a small wrapper type, something like StructuralManuallyDrop, in a separate crate, that exposes these suggested features. That would allow anyone willing to use this dependency to get the same benefits as if this functionality was added to ManuallyDrop directly.
What happens now?
This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.
Possible responses
The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):
- We think this problem seems worth solving, and the standard library might be the right place to solve it.
- We think that this probably doesn't belong in the standard library.
Second, if there's a concrete solution:
- We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
- We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.