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.
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.