Repository navigation
element drop order inconsistent between in-progress versus completed arrays #23222
Description
This code:
use std::thread;
struct D(u32);
impl Drop for D {
fn drop(&mut self) {
println!("Dropping {}", self.0);
}
}
fn main() {
fn die() -> D { panic!("Oh no"); }
let g = thread::spawn(|| {
let _a: [D; 3] = [D(101), D(102), D(103)];
let _d: [D; 4] = [D(401), D(402), die(), D(404)];
});
assert!(g.join().is_err());
}prints
Dropping 402
Dropping 401
Dropping 101
Dropping 102
Dropping 103
i.e. when the panic occurs, we do the dropping in reverse order for the array being built, but then we do the drop in "declaration order" for the array that was fully constructed.
See also rust-lang/rfcs#744 and #16493
Activity
steveklabnik commentedon Sep 3, 2015
/cc @rust-lang/lang
steveklabnik commentedon Feb 7, 2017
Triage: today, this is the same. rust-lang/rfcs#1857 is an RFC specifying drop order; I'll leave a comment over there.
nikomatsakis commentedon Feb 11, 2017
@pnkfelix odd as that seems, I consider this to be "behaving as expected". That is, we would do the same for structs that are under construction, for example, where we drop the fields assigned so far (in reverse) as part of unwinding, but once it is built we drop differently.
pnkfelix commentedon Feb 15, 2017
@nikomatsakis yeah this issue is from almost two years ago; my mindset about what's "expected" has changed since then, so I'll close this.
pnkfelix commentedon Feb 15, 2017
(though I do see an argument, and perhaps this is what was underlying this issue, that if we did change to reverse order field/element destruction, then the semi-surprising behavior described by this issue would just "go away")
Merge pull request rust-lang#23222 from BenjaminBrienen/outdated-comm…