{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreib362mwmay4zxlmz6n5fex3oj72uzoroxn235rp5ygyjpw7xmh7aq",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mm2k6yobm3t2"
  },
  "path": "/t/pre-rfc-improved-ergonomics-for/24336#post_5",
  "publishedAt": "2026-05-17T12:20:48.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "robofinch:\n\n> Imagine that someone had `UninhabitedErr<T, E>(Result<T, E>)` whose safety invariant is that `E` is an uninhabited 1-aligned ZST, as enforced by `unsafe` constructors?\n\nThat's a good example. I've bookmarked for later (if there is a later).\n\nIf I understand correctly: constructing an `UninhabitedErr<T, E>` would be `unsafe`. Which would make the validation simple: can both types be constructed without unsafe.\n\nrobofinch:\n\n> (Note: I have my “library author” hat on, I’m not a compiler dev. So, I’m used to being very paranoid to attempt to write bulletproof `unsafe` code, while the compiler devs probably have a better grasp of what sorts of code actually exist out there, and the language does occasionally make breaking changes after a lot of communication.)\n\nI'm also coming at this as a library author with a similar view of unsafe . And \"could break unsafe code\" has been the killer for any previous attempts to look at this - which is a stance I'm not going to challenge (both because I agree with it and I don't have anywhere the background to do so)",
  "title": "Pre-RFC improved ergonomics for `!`"
}