{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigs6ecqgtmmppg5x6lqcgnn4n3bysiww6ebekcdcxvzttdig7p6k4",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mpk6b6obcxt2"
  },
  "path": "/t/language-vision-regarding-safety-guarantees/24418?page=2#post_23",
  "publishedAt": "2026-06-30T22:25:36.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "@scottmcm",
    "The Hashtable Problem: A Litmus Test for External Impl Proposals"
  ],
  "textContent": "dlight:\n\n> If it actually triggering UB is not a sensible future direction for this API, it seems much better to just remove the `unsafe` tag from it (existing callers won't be negatively affected, but they may drop the unsafe block if they wish)\n\nI guess the complexity here is something that @scottmcm brought up in another thread:\n\nThe Hashtable Problem: A Litmus Test for External Impl Proposals\n\n> It's really important to me that for `HashSet<TrustedType>`, if someone gives me one it actually works. I don't want to ever let someone give me a garbage `HashSet<u32>`, for example. I want to be able to trust it because I trust `u32` and I trust `HashSet`.\n\nI think there's a core tension here between the desirable requirements \"a `BTreeMap<K,V>` for which I know that `K`'s `Ord` implementation is correct should always be ordered\", and \"`BTreeMap<K,V>` should be memory-safe regardless of how badly behaved `K`'s `Ord` implementation is\". Both of these requirements are potenitally important to avoid memory-safety vulnerabilitiies: the latter requirement is required if someone writes a broken `Ord`, and the former requirement is required if unsafe code relies on a `BTreeMap<u32,V>` to be correctly ordered.\n\nFor the first requirement to hold, `btree_map::CursorMut::insert_before_unchecked` needs to be `unsafe`, which effectively declares having an unordered `BTreeMap<u32>` to be library UB.\n\nFor the second requirement to hold, `btree_map::CursorMut::insert_before_unchecked` needs to be safe: otherwise, giving a `BTreeMap` a `K` with a broken `Ord` implementation is library UB, because it leads to an `unsafe` method being called without actually upholding its safety requirements.\n\nAs such, we basically have a weird case of specialisation here: the implication is that `btree_map::<K,V>::CursorMut::insert_before_unchecked` is safe whenever `K` is a downstream type (and that having an incorrectly sorted `BTreeMap` is library UB in this case), but `unsafe` whenever `K` is a standard library type (and that having an incorrectly sorted `BTreeMap` is _not_ library UB in this case, just a logic error).\n\nI'm not sure that there's any sensible way to cover this gap. (It almost seems as though the \"safety level\" or \"trust level\" should be some sort of generic parameter, but I can't think of a way to make that work.)",
  "title": "Language vision regarding safety guarantees"
}