[Pre-RFC]: Specify and stabilize drop order

language design
21

The point of this RFC is that the current drop order is de-facto stabilized, because there are libraries on crates.io that rely on it. And as @sfackler put it, there is no upgrade path if the drop order is changed (either an old compiler will produce incorrect code or a new compiler will).

Fortunately, adding opt-in drop orders in the future will still be possible (for instance, by annotating a struct with #[drop_order(...)]).

22

I don't disagree, it'd be great to fix! But I think there is a substantial amount of design left to go. Regardless, I think there is still a legitimate reason to stabilize drop order:

  1. Drops can have other side effects besides using references (i.e., sending messages).
  2. Even with safe references, you have to drop the references before the thing they refer to, so we would have to specify that (think dropck).

Now, point 2 could be argued as a reason to reverse the existing drop order, in that right now if you had a struct with an arena and a ref into that arena, it would have to look like:

struct Foo {
    r: RefIntoArena, // so that this gets dropped before `arena` gets dropped!
    arena: Arena,
}

This is why C++ reversed the drop order, and why we initially had it that way. To be perfectly honest, I'm not sure why it was changed. :confused: (Can't remember; heck I probably approved it) But I kind of feel like it's not worth the breakage to do anything about it; it's sort of arbitrary, after all, and dropping in-order is also fairly intuitive.

23

Just pushed the RFC! Here is the PR

24

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.