Matthew House
Matthew House
Both are acceptable. In `function::drop_closure()`, you can either write `mem::forget(err)`, `mem::forget(catch_unwind(|| drop(err)))`, or `catch_unwind(|| drop(err)).unwrap_or_else(|_| process::abort())` (maybe with an extra `AssertUnwindSafe`). You can do the same in `PanicException::from_panic_payload()`. Also, the...
> Or some other method of traversing, such that I could say "select first item, select next nested item, select next nested item" without using the key name directly? If...
I'd like to rehash my [earlier arguments against this change](https://github.com/rust-lang/lang-team/issues/97#issuecomment-1163791983), for those starting from this issue. I'd like to begin with some statements that I think everyone here agrees with:...
> In order to justify changing the default, the RFC should justify the claim that RAII drop glue is an issue, and not just explicit `drop_in_place` calls unwinding. I would...
To provide an extra data point, I've found some widespread FFI code that intentionally relies on calling `resume_unwind()` within `Drop::drop()`. In [`openssl`](https://crates.io/crates/openssl) v0.10.41 (and its fork [`boring`](https://crates.io/crates/boring) v2.0.0), the associated...
> Another complaint from that thread is that `Send` and `Sync` _ought_ to logically imply `UnwindSafe` and `RefUnwindSafe` (respectively), but don't. Why should this logical implication hold? As I understand...
> If you share an object between threads, you are already crossing unwind boundaries as unwinding stops at thread boundaries. IMO only Sync should imply UnwindSafe, as for Send sharing...
> `&&mut T` is effectively equivalent to `&&T`, which should implement `UnwindSafe` for `T: RefUnwindSafe` (it doesn't currently as there is no `impl RefUnwindSafe for &T` right now for some...
> So in any case where there's an opportunity for `catch_unwind()` to observe your broken invariant, there's also an opportunity for a concurrently-running thread to observe it. Consider the example...
> I'm not sure if you were just pointing out a technical detail, or if you intended this as a broader counterargument...? My apologies; I hadn't seen that you were...