upvote
I've written dozens of custom Drop implementations. Well, many of them are named cleanup because of the async Drop mess in Rust, but...
reply
How many of them only conditionally implement Drop, based on a generic param lifetime?
reply
Why 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.
reply
Therefore explaining why the bug hadn't been hit in practice for 11 years.
reply
The 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.
reply
This code, from the bug submission?

  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)); } }
  }
The bound on T in the Drop impl means Drop is not implemented for all T, only where T: 'static + Send. Q<T> also having the same bound doesn't make a difference to the Drop impl.
reply
You cannot write a type which conditionally implements Drop: https://play.rust-lang.org/?version=stable&mode=debug&editio...

    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>);
      | ^^^^^^^^^^^
reply
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).

You also don't have to place those bounds on the Drop impl just because they're on Q, that's not an error.

reply
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
That's easily the exception rather than the rule. I've seen custom `Drop` implementations in almost every non-trivial Rust codebase I worked on.
reply
A custom `Drop` appears very quickly with FFI code. Suppose for example you interface with some C library that expects you to call a function to release some resources.
reply
deleted
reply
Now we are at the phase where, Rust is “safe” but only if you use it “correctly” and without using X language feature or a custom Y feature.

This is the problem when a language advertises with “guarantees” and it turns out it never had any due to many false assumptions by their promoters.

So what other soundness bugs are there in the language that we need to know about?

reply
I'm not defending rust here - a correctness bug invalidates the premise. But I am saying that I've never seen a custom drop in production.

For some reason this is controversial, but it remains true.

reply
You said/implied 2 things:

- you've never written a custom Drop

- "Not really". Implying that your experience generalizes

I've written a bunch of rust programs without custom Drop. I believe your first statement. There are large classes of programs that don't need it. There are also many that do. I think your statement says a lot more about what kind of programs you work on than about custom Drop not being common. People are downvoting the implication that custom Drop is not a common pattern.

reply
Custom drops are all over the place. As others have said.

But not custom drops that are doing variadic type stuff like this, usually.

reply
No we're in a situation where a bug in the type checker was found and will be fixed and a new release will be made.

That it took 11 years for someone to come across this is a fairly intense counterargument to your attempt to paint this as a language with dangerous footguns.

reply
[flagged]
reply
A gun in a glass case with a warning label reading "do not aim at foot"?
reply