{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiapq7m4en2ws25m5b5vaxbqruxtw44r2gjyz4n52dqogwah2h3iyq",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mptkngdctiq2"
  },
  "path": "/t/language-vision-regarding-safety-guarantees/24418?page=3#post_56",
  "publishedAt": "2026-07-04T16:25:22.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[1]",
    "↩︎"
  ],
  "textContent": "tczajka:\n\n> Same thing for deciding whether to trust dependencies for soundness purposes. There is no convention that absolves you from that responsibility.\n\nThis is the distinction between \"deciding to trust\" and \"what it means to trust\" as we discussed before. I agree it's subtle, so I'll try again (otherwise it should deserve its own thread). As a crate author you get to choose which dependencies (and which parts of them) you use and how you use them. When you do so, you trust whatever you decided to use to be correct for how you decided to use it (otherwise you wouldn't use it). That's the \"deciding to trust\" part. Now what it means to be correct is defined by the dependency and the language. That's the \"what it means to trust\" part. In particular, you don't choose what it means for the dependency to be correct, you only get to choose whether to use it (thus trust it to be correct).\n\nAs an example we got earlier. Someone may decide to use the standard library. They may decide to use `Box` and `Vec` in unsafe code (thus use/trust the safety contract of those APIs), but use `BTreeMap` in safe code only (thus its logic contract), since a dependency of safe code being incorrect is not that bad, it can't cause undefined behavior. They did so because they estimated that using `BTreeMap` in unsafe code is too risky (there's non-negligible chance `BTreeMap` is incorrect for safety). But they did not decide the logic and safety contracts of the standard library, the standard library and the language did. They just chose what to use and for which purpose based on those contracts.\n\nI'll update the top post because I agree this is subtle and I assumed this implicit aspect was clear. So actually a possible explicit version of the statement provided by the language today is: \"safe code cannot cause UB _assuming everyone involved follows the language convention_ \" (where the implicit part is in italic). This convention is: units of implementation are correct for safety. What it means to be correct for safety is defined by the unit of implementation (the safety requirements of their unsafe API) and the language (the safe API must have no safety requirements, and the logic contract is a safety guarantee[1]).\n\n* * *\n\n  1. this last part is the topic of this thread and the contradiction is that safe code is not necessarily correct for safety ↩︎\n\n\n",
  "title": "Language vision regarding safety guarantees"
}