{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicji5wywrpd3dg3xll5mtd46vlvuwzhrfpgfjq4gr4tqt22blrzvq",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mpsiyuvjfhp2"
  },
  "path": "/t/language-vision-regarding-safety-guarantees/24418?page=3#post_54",
  "publishedAt": "2026-07-04T05:46:47.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "tczajka:\n\n> Safety requirements don't create two versions of the contract, they just provide a boundary to what the contract promises. There are no guarantees at all outside of the boundaries of what safety requirements require. It's just undefined behavior in that scenario.\n\nI see. So in my terms your single contract is the safety contract with the convention. It indeed contains all the information, but doesn't leave room to talk about a language with a different convention. Since you are in favor of the convention, it indeed makes sense to not consider another point of view.\n\nrobofinch:\n\n> I don’t see why either perspective is objectively wrong.\n\nAssuming the convention, the single contract is objectively better, because there's just one contract. (In this case the language only guarantees that \"safe code _in clients_ cannot cause UB\".)\n\nDiscussing alternative conventions (like the Rust Hypothesis or explicit safety guarantees, to try to restore \"safe code cannot cause UB outside its unit of implementation\"), the 2 contracts is objectively better, because there's no other option.\n\nSo without knowing in which of those 2 scenario we are, no perspective is indeed objectively wrong. However, given that this thread is about the language contradiction between the convention and \"safe code cannot cause UB\", I believe it helps to temporarily (within this thread) use the 2 contracts perspective.",
  "title": "Language vision regarding safety guarantees"
}