element drop order inconsistent between in-progress versus completed arrays

[pnkfelix]

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

[steveklabnik]

/cc @rust-lang/lang

[steveklabnik]

Triage: today, this is the same. rust-lang/rfcs#1857 is an RFC specifying drop order; I'll leave a comment over there.

[nikomatsakis]

@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]

@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]

(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")