{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigsjtvfo7j5bsn3uiowrvrh3a5x6dq746eyxmnz36ucjhwd3bzaj4",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mpipbofyhz52"
  },
  "path": "/t/language-vision-regarding-safety-guarantees/24418#post_9",
  "publishedAt": "2026-06-30T09:18:03.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "ais523:\n\n> he interesting thing about this method is that it's marked `unsafe`, even though abusing it shouldn't be able to cause undefined behaviour (only logic bugs):\n\nWhenever an API marked as `unsafe` causes only logic bugs when misused, rather than actual memory safety issues, I think it's best to ignore the logic thing and suppose that, even though currently it does not actually trigger UB, in the future, new semver-compatible versions of this API hold the right to trigger UB \"as promised\". So the API is _allowed_ to trigger UB when misused (and allowed to do anything else, including having a safe logic bug), but not required to do so at any given moment.\n\nSo what the stdlib is saying is that it could, at some point in the future, actually trigger UB in this operation, even if it's not doing this today. And as such, it's UB in this sense (you do something, it might cause UB sometimes, you can't rely on it to not be UB, ergo it is UB in some abstract sense)\n\nIf 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)",
  "title": "Language vision regarding safety guarantees"
}