> You yourself said that web servers are a place where this is a good idea.
I said that "panicking from Drop::drop is a bad idea, but that panicking is a good idea in general (e.g. in web servers)".
We are in agreement that panicking is a good idea in general, but you seem to be turning that around, arguing that "Panicking is a good idea in general, therefore panicking from Drop::drop is a good idea". One does not follow from the other.
If you believe that unwinding from Drop::drop is a good idea, enumerate the value this feature adds, its costs, and make a case about why this trade-off is worth it.
All languages with unwinding in the same space as Rust do not allow unwinding from destructors, because it adds no value, and adds significant costs. For example, C++ and D do not support it. C++ used to support it, like Rust, but considered the value it added as "negative" (that code deserved to be broken), and changed its semantics to forbid this by default. AFAICT, the same arguments that apply there, apply 1:1 to Rust.
In Rust, the cost of this feature is real, e.g., from basic impls like the impl of `Drop` for slices, reused by most collections, to pretty much every Drop impl of every type guarding an important resource in a module that uses unsafe (e.g. the many Iterator drop guards, etc.).
So I stand by my original claim: panicking from Drop::drop is a bad idea: there are no worthy use-cases for it, its costs are real, pervasive, and unnecessary, because in practice nobody does this, but every writer of unsafe code must write code to defend from it, which makes trickier code even trickier to write, read, and properly test.
> If you believe that unwinding from Drop::drop is a good idea, enumerate the value this feature adds, its costs, and make a case about why this trade-off is worth it.
I don't believe it's a good idea, which I have repeated in this thread numerous times. You seem to keep implying that it's an often used and good idiom, and I keep saying that it's not, which is why it's not used. Most of your points are about unwinding generally, not unwinding from Drop. I think it's really confusing the issue here.
I don't really think this is productive. It seems we're in agreement about one thing, though I am very confused as to how. Let's just leave it at that.
> You seem to keep implying that it's an often used and good idiom,
I said that this is code that safe Rust allows you to write [0] - it's actually safe code that beginners could write by accident [1] - and therefore all unsafe Rust programmers need to actually write Rust code that defends against this happening: otherwise their safe Rust APIs over unsafe Rust code are unsound, because if someone were to write safe Rust programs like [1], their unsafe Rust code would exhibit undefined behavior (the standard library and the language itself being the prime examples of this [2]).
The claim that panicking from Drop::drop will often cause a double-drop or terminate the program assumes that all unsafe code is written by people that properly defend all their unsafe code against it happening. We agree that no reasonable programmer would purportedly write such Drop impls, so I doubt that. It suffices for execution to reach a path that isn't properly guarded for the program to exhibit UB, and at that point, there aren't any guarantees about double-drops panicking or aborts doing anything meaningful.
That is, we have a feature we agree on does not do anything useful, yet adds a cost to all unsafe code.
[0] As opposed to C++ or D, which do not allow you to write Drop::drop implementations that unwind/fail, and therefore their programmers do not need to write code to protect themselves from something that nobody does, just in case somebody actually ends up doing it by accident.
[1] As easy as:
struct S;
impl Drop for S {
fn drop(&mut self) { unimplemented!() }
}
[2] These safe code example are actually used by the standard library test suite to test, e.g., the collections. So it isn't just the cost of having to read/write unsafe code that protects against something that does not make sense doing, but also the cost of then adding and maintaining the tests for those code paths.
I said that "panicking from Drop::drop is a bad idea, but that panicking is a good idea in general (e.g. in web servers)".
We are in agreement that panicking is a good idea in general, but you seem to be turning that around, arguing that "Panicking is a good idea in general, therefore panicking from Drop::drop is a good idea". One does not follow from the other.
If you believe that unwinding from Drop::drop is a good idea, enumerate the value this feature adds, its costs, and make a case about why this trade-off is worth it.
All languages with unwinding in the same space as Rust do not allow unwinding from destructors, because it adds no value, and adds significant costs. For example, C++ and D do not support it. C++ used to support it, like Rust, but considered the value it added as "negative" (that code deserved to be broken), and changed its semantics to forbid this by default. AFAICT, the same arguments that apply there, apply 1:1 to Rust.
In Rust, the cost of this feature is real, e.g., from basic impls like the impl of `Drop` for slices, reused by most collections, to pretty much every Drop impl of every type guarding an important resource in a module that uses unsafe (e.g. the many Iterator drop guards, etc.).
So I stand by my original claim: panicking from Drop::drop is a bad idea: there are no worthy use-cases for it, its costs are real, pervasive, and unnecessary, because in practice nobody does this, but every writer of unsafe code must write code to defend from it, which makes trickier code even trickier to write, read, and properly test.
C++ is the sane language here. Rust is not.