How many of them only conditionally implement Drop, based on a generic param lifetime?
replyWhy would you ever conditionally custom impl Drop? I don't think I've ever seen that pattern, and I can't think of a use case.
replyTherefore explaining why the bug hadn't been hit in practice for 11 years.
replyThe bug in the OP is about UNconditional impl. And honestly, looks like very standard code, definitely something that could've been written for real. I can't even explain why it passes checks, it clearly shouldn't.
replyThis code, from the bug submission?
reply impl<T: 'static + Send> Drop for Q<T> {
fn drop(&mut self) { if let Some(t) = self.0.take() { KEPT.lock().unwrap().push(Box::new(t)); } }
}
You cannot write a type which conditionally implements Drop: https://play.rust-lang.org/?version=stable&mode=debug&editio...
reply struct Q<T>(Option<T>);
impl<T: 'static> Drop for Q<T> {
fn drop(&mut self) {}
}
error[E0367]: `Drop` impl requires `T: 'static` but the struct it is implemented for does not
--> src/main.rs:3:9
|
3 | impl<T: 'static> Drop for Q<T> {
| ^^^^^^^
|
note: the implementor must specify the same requirement
--> src/main.rs:1:1
|
1 | struct Q<T>(Option<T>);
| ^^^^^^^^^^^Even if the bounds are the same on the struct and the impl, it's still true that placing bounds on the Drop impl means it's not implemented for all T (just all T that also satisfy Q).
replyYou also don't have to place those bounds on the Drop impl just because they're on Q, that's not an error.
OK. That's good to know. I'm not sure why sharing our professional experience with this type of code is controversial, but here we are.
reply