Can you elaborate? A panic is a panic, and it will either unwind or abort if unwinding is interrupted with a second panic. There's nothing silent about that.
If you do this:
spawn(proc() { panic!("hmmph"); });
Then "nothing" happens. The default, correct, behaviour for "unhandled" errors is to abort the program. Rust apparently thinks it doesn't need this, because "poisoning". Which is a great thing, except it still doesn't excuse silently swallowing errors. It's one way to end up with a half-dead process. And considering Rust's overall strict handling of errors, it seems bizarrely counter-intuitive to go with the silent route here.
The .NET team went through the exact same process and ended up taking a breaking change in v2 to fix their handling of background exceptions (so now they crash the app unless you opt-in to handling them).
Ah, I see, I wasn't aware that a panic in a child task no longer panicked the parent task. That was surely the case in older versions of Rust, but I have no idea when it changed. Thanks for the RFC!
Well it can't just panic the "parent" - the parent is an arbitrary thread running so you'd have to find a way to inject faults into the parent. I'm guessing with Rust's older task system, you could handle it there, since you owned the scheduler?
With the new, threads-only system, I think the only way out is abort.
