TIL removing an explicit Drop impl and relying on drop glue is a breaking change

And I'm quite disappointed :disappointed:

trait A {
    fn uhoh() {}
}

impl<T: Drop> A for T {}

fn main() {
    regex::Regex::uhoh(); // error: Regex doesnt directly impl Drop (at least the current version on the playground)
    Box::<()>::uhoh(); // not an error: Box directly impls Drop
}

One could argue that you aren't supposed to use Drop bounds, so it might not actually count as a breaking change.

There's other kinds of breakage that doesn't count as a breaking change. E. g. accessing items that have hidden documentation can introduce breakage when libraries are updated. Or using deny on a warning class can introduce breakage on compiler upgrades. Not to mention that there's also accepted breakage like potential for ambiguities from multiple ::* imports that can bite you when items are added to libraries. Or ambiguities when different traits have methods that are named the same, causing breakage when a method is added to a trait.

2 Likes

Well, #[pin_project] disagrees (thankfully only for a type local to where you write #[pin_project]).

Adding a Drop impl is also a breaking change because const fn doesn't handle destructors.

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.