Don't Panic: The Hitchhiker's Guide to Unwinding
lucumr.pocoo.org
lucumr.pocoo.org
For: for some domains, you really, really, really want to be able to handle panics. For a notable example, one of the first production deployments of Rust is a Ruby gem that runs inside of a client's Rails process (https://www.skylight.io/). Without the ability to unwind, a panic in your Rust code would bring down the whole process (henceforth an "abort"), and your paying customers will probably be somewhat peeved. Servo is also looking to leverage unwinding, so that a panic in one tab doesn't abort the entire browser process.
Against: the concept of unwinding is inherently flawed in some very pernicious ways. Say you're the user in the previous paragraph who needs to catch panics. You have everything set up properly, and when your code panics you're prepared: the stack unwinds, freeing resources and calling destructors. Everything is peachy. But here's a twist: while unwinding, what happens if one of your destructors panics? The process aborts, is what happens. You've setup all this machinery for apparently nothing at all. And generating all the machinery for unwinding is a hit to compile time, bloats binary sizes, and can potentially thwart optimizations in the generated code.
I don't think it would be uncontroversial to provide unwinding as an option. The biggest question here is whether or not that option would be enabled or disabled by default, as it would have implications for distributing compiled binaries (though perhaps Cargo could assist with this).