Will destructors create &mut references only when Drop::drop() is called?

[theemathas]

Consider this code, which implements a construct similar to Arc, but points to the stack, and will abort the program if you try to deallocate the backing allocation while there are still outstanding references.

The parts of the code that is relevant to the question is as follows:

struct StorageGuard {
    // omitted
}

struct StorageInner<T> {
    data: T,
    // omitted
    _phantom: PhantomPinned,
}

pub struct Storage<T> {
    guard: StorageGuard,
    inner: StorageInner<T>,
}

impl Drop for StorageGuard {
    // omitted
}

The Storage type has public methods that effectively hands out &T references to the data inside, but with an unbound lifetime. To make this sound, the Drop impl of StorageGuard checks whether there are any outstanding references to the data, and will abort the program if there are.

The destructor of Storage<T> consists of two steps:

1. Call <StorageGuard as Drop>::drop().
2. Call <T as Drop>::drop().

Note that step 1 checks whether there are any &T references, and step 2 creates a &mut T that would potentially alias with any such references. Therefore, this unsafe code assumes that the &mut T is only created on step 2. Note that &mut Storage<T> is never created, since Storage doesn't implement Drop.

Is it OK for unsafe code to assume that the destructor will never create any &mut T references until the point where Drop::drop is called?

[RalfJung]

Is it OK for unsafe code to assume that the destructor will never create any &mut T references until the point where Drop::drop is called?

IIRC, drop_in_place acts like it basically takes an &mut argument. So, the answer to your question is "no".

[RalfJung]

Also see #373