Potential generalization of destructing struct destructuring

Issue by glaebhoerl
Monday Jan 27, 2014 at 21:17 GMT

For earlier discussion, see https://github.com/rust-lang/rust/issues/11855

This issue was labelled with: in the Rust repository

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.

Start with the earlier discussion in Rust issue #11855, then review the proposed interaction between struct destructuring, Drop implementations, and field drop glue described here. Done would require a settled design or RFC decision that defines whether this generalization is sound and what behavior it requires.