{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihdxij3ph6z6bob54ndpubkgedc34x2jjsvbhiyvzfzzn5pn7flfq",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mlyu6z3gjgu2"
  },
  "path": "/t/pre-rfc-improved-ergonomics-for/24336#post_3",
  "publishedAt": "2026-05-16T20:17:08.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "MusicalNinjaDad:\n\n> Or rather, the implicit conversion will only take effect _if it is safe to do so_.\n\nHow is this determined? 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\nYes, this is an absurd scenario with a useless type, but it would then be _unsound_ to coerce `UninhabitedErr<T, !>` to a general `Uninhabited<T, E>` where `E` may be a non-ZST or inhabited type.\n\nI worry that determining whether adding a _new_ coercion of this sort which affects existing code could be unsound, so it’d probably need to be opt-in… in which case I’m not sure that the solution would address all your wishes.\n\n(Maybe `UninhabitedErr` could be seen as unsound for relying on negative reasoning about what coercions will be possible in future Rust versions.)\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.)",
  "title": "Pre-RFC improved ergonomics for `!`"
}