{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicgo3ya2krzv2tnb7bbgzrxtfev2gsh7axs3aeesprqxgkfk25jim",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mptre7hhhc62"
  },
  "path": "/t/language-vision-regarding-safety-guarantees/24418?page=3#post_57",
  "publishedAt": "2026-07-04T17:21:47.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "ia0:\n\n> 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.\n\nThat's perfectly fine, that matches what I'm saying. You are free not to trust `BTreeMap` enough to use it for soundness purposes, so just don't use it for soundness purposes. You can do that today, no need to change anything in `std`. There is no need for `BTreeMap`'s interface or documentation to say anything about this. You can already not use it if you don't want to trust it.\n\nBTW, you seem to be confusing \"using `BTreeMap` in your own `unsafe` code\" vs \"using `unsafe` APIs of `BTreeMap`\". These are two separate choices. It's possible to use safe `BTreeMap` APIs in your own `unsafe` code.\n\nBut either way, you are already free to have any policy you want regarding whether you use `BTreeMap` for `unsafe` purposes in your own code. There is no need to change anything in `BTreeMap` to enable that.",
  "title": "Language vision regarding safety guarantees"
}