Backwards-compatability issue with non-zeroing drop

Rust 1.0.0-alpha ensures that destructors don’t do anything on types that are zeroed-out, which has performance costs. Currently, this is needed to ensure that destructors don’t get called twice, but this is planned to be removed (RFC PR 320).

However, programs (for example the current implementation of sift_up of BinaryHeap in libcollections) rely on that, which would make changing this a backwards-compatibility issue.

(Spawned from IRC discussion on #rust-internals, log here: https://botbot.me/mozilla/rust-internals/2015-02-03/?msg=31120395&page=9 )

Alternatively, one could call the treatment of zero’ed data undefined behavior, or call the contents of the memory that the dropped variable occupied “undefined”, and consider programs that rely on this behavior (such as the current implementation of sift_up) to have a bug that just-so-happens to work in current Rust. In that case, sift_up (and other problem cases in the standard library) should be fixed pre-1.0, but it isn’t necessary to fully remove zeroing now.

It’s probably my C background showing, but I actually like having specific areas of UB in a language, since they give the compiler more freedom to optimize.

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