Description
Currently structs with destructors are (sensibly) not allowed to be move-destructured (#3147), because then when their destructor runs, it would access deinitialized values.
This could potentially be generalized if we recognize that a destructor, in other words drop glue, is not an indivisible thing. It consists of the Drop impl for the struct itself, and the destructors for each of its fields. Therefore if we write:
struct S { a: A, b: B }
impl Drop for S { ... }
let s = make_some_s();
let S { a, b } = s;
when the destructuring happens we could run the Drop impl for S, but not the drop glue for A and B. Those are then moved out, and their destructors will run later, whenever they go out of scope.
I believe this is sound: Drop::drop() takes &mut self, so it can mutate the components of S but not deinitialize them. If we broaden our considerations to unsafe code, then if the fields of a struct S have destructors themselves, then the Drop impl for S must, even today, leave them in a valid state, because those destructors will then access it. It is only cases where the fields of S do not have their own destructors, and the Drop impl for S uses unsafe code to put them in an invalid state, which would become dangerous, and we would have to be very careful about.
We'd obviously have to think about whether we actually want this (I haven't thought of any use cases yet), but as a theoretical possibility, I think it checks out.