should struct fields and array elements be dropped in reverse declaration order (a la C++)

[pnkfelix]

should struct fields and array elements be dropped in reverse declaration order (a la C++) ?
#16493 made us internally consistent with respect to struct fields, but chose to make the drops follow declaration order.

Note struct construction follows the order of the fields given at the construction site, so there's no way to ensure that the drop order is the reverse of the order used at the construction site.

But we should still think about whether we should change that. That is, if local variables are dropped in reverse declaration order (even though they can be initialized in any order), then it seems like it would make sense to do the same thing for struct fields.

[lilyball]

Local variables do indeed drop in reverse declaration order, not reverse initialization order.

struct Dropper {
    name: &'static str
}

impl Drop for Dropper {
    fn drop(&mut self) {
        println!("Dropping {}", self.name);
    }
}

pub fn main() {
    let _a: Dropper;
    let _b: Dropper = Dropper { name: "b" };
    _a = Dropper { name: "a" };
    println!("main");
}

prints

main
Dropping b
Dropping a

[lilyball]

How about tuples? They also drop in forwards order.

And what about library-defined collections, like Vec?

[lilyball]

Or fixed-length arrays, which also drop in forwards order? And of course enums and tuple-structs do too, though those can be considered variants of tuples.

[lilyball]

Unboxed closures drop by-value-captured upvars in the order in which they were first referenced in the closure body.

[lilyball]

I am sympathetic to the idea that struct fields should drop in reverse order, but it's harder to justify dropping tuples in reverse order, and I cannot justify dropping fixed-length array elements in reverse order. Given that structs, tuples, and (assuming all fields are the same type) fixed-length arrays are basically isomorphic to each other, they should all drop values in the same order, and since I can't justify reversing the order for arrays, that indicates that structs should drop in declaration order.

Another way to look at this is to say that variable bindings vs value fields are different things. Value fields are just components of a value, and values always drop components in declaration order. On the other hand, variables are independent declarations with independent lifetimes, and the nesting of these lifetimes requires LIFO drop order. To put it another way, a scope is a stack of values, so the stack drops in reverse order as it pops, but each independent value is not a stack, and so there is no reverse ordering.

[pcwalton]

C++ arrays drop in reverse order. Why not Rust?

[lilyball]

They do? Interesting. Arrays are ordered collections, and to me, that means they should drop in order. If you want to flip the order for arrays, how about Vec? Or what about other ordered collections, such as TreeMap?

[lilyball]

FWIW, Swift drops struct fields, tuple fields, and Array elements in order.

[pnkfelix]

(I'm getting the impression that this could be worth an RFC, hmmm ...)

[pnkfelix]

(added arrays to the scope of the issue)

[steveklabnik]

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#744