{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifelsr2itrew5t2lttxvtusjjddow7oii7254zn3jypw6pcbfzz64",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mjmlau5ny2j2"
  },
  "path": "/t/code-bloat-caused-by-lack-of-nounwind-attr-on-drop-in-place/24173#post_7",
  "publishedAt": "2026-04-16T13:41:52.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "Panic - The Rust Reference",
    "Drop in std::ops - Rust",
    "Destructors - The Rust Reference",
    "panic in std - Rust"
  ],
  "textContent": "Hang on, is panicking in Drop actually guaranteed not to unwind? Panicking _during unwinding_ results in an abort, which means panic-in-Drop is ill-advised, but I'm not sure the language has actually ruled it out.\n\nNothing in\n\n  * Panic - The Rust Reference\n  * Drop in std::ops - Rust\n  * Destructors - The Rust Reference\n  * panic in std - Rust\n\n\n\neven mentions that panicking while already unwinding results in an abort, let alone that panicking in Drop is always forbidden. Thus, as far as I can tell, panicking in Drop is legal, as long as it never happens in practice while another panic is being processed. (But hopefully I've just missed the appropriate reference!)",
  "title": "Code bloat caused by lack of nounwind attr on `drop_in_place`"
}