Tracking issue for RFC 1857: Stabilize drop order

[aturon]

RFC

For this RFC, what's needed is documentation. There's no behavioral change or feature-flag stabilization.

[aochagavia]

Besides documentation, I think a couple of tests would be useful as well to prevent accidentally changing the order.

[aochagavia]

@aturon In the RFC I mentioned updating the book, but upon second thought relying on a particular drop order seems to be a niche use case. Therefore it seems reasonable to me to omit it in the book and only mention it in the reference. Do you agree with that?

[vitalyd]

The book should mention that the drop order is specified, but can refer the reader to the reference for elaboration.

[aochagavia]

@steveklabnik @carols10cents I am trying to find a good place in the book to put tell that drop order is specified. I guess if we were to do this it would go in the chapter about drop. Unfortunately, the example uses a struct with only one field, so we cannot use the example to talk about drop order. Maybe we could add an extra field and then explain which field is dropped first? Then, we could link to the reference for more information.

I am still not sure about mentioning drop order in the book, so I am also interested in your opinion regarding that.

[steveklabnik]

Yes, we should mention it; we already do in the lifetimes section, I believe. The drop chapter is the right place though, and another example is a good idea.

[arielb1]

The "panic during initialization drops elements in reverse order" is actually a part of the "temporary lifetimes" rules, which are described in https://github.com/nikomatsakis/rust-memory-model/issues/17. Do we want to document them?

[Centril]

I believe there's nothing left to do here, so closing.