I didn't want to suggest it's undefined, I said weird. In C++, it's reverse declaration order, and that's important because destruction exactly mirrors construction. Arguably, Rust is completely wrong here, but my experience is that this problem doesn't come up in idiomatic Rust all that often because fields can't depend on each other anyway. And I'm wildly speculating of course, but something like that might be more of an issue if a lot of unsafe C++ objects are instantiated from within Rust.

I see, I misunderstood how you said that, but I get it now. :) Sorry about that!

Yeah, the fact that it's the opposite in C++ was a huge point of contention before we defined it; changing what was there risked breaking a lot of code, and there are good reasons for either order. But yeah, I had to go and look at the RFC for exactly the reasons you state; it just isn't normal to care about this at all, so it's easy to not remember.

Just because fields can't depend on each other in code doesn't mean that the side effects of those fields don't matter: Rust is only guaranteeing memory safety, not semantic safety... like, if you are tracking file handles or networked objects or bicycle messengers, it can easily (and even often) be very important that objects deconstruct in the reverse stacking order of their construction. I am so glad I read your comment here as I could easily see myself one day starting to use Rust and going insane from this decision :(. (The more I think about this the more concerned I honestly am as I am not even sure how to implement many paradigms correctly without this basic deconstruction stacking order property.)

> The more I think about this the more concerned I honestly am as I am not even sure how to implement many paradigms correctly without this basic deconstruction stacking order property

Don't you just define a destructor[1] and make it explicit? Or maybe I'm missing something subtle here?

1: https://doc.rust-lang.org/reference/destructors.html