{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibc3a7bwhwtwfctmtrn3sm4lqxmcj6i33dzwdw5qmz76jq3vgwvfi",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mfvltr5ulrn2"
  },
  "path": "/t/impact-of-static-variables-on-api-soundness/24039#post_2",
  "publishedAt": "2026-02-26T17:28:35.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "hxuhack:\n\n> In the current implementation, I believe `do_critical_task` can be declared safe. Is this correct?\n\nYes.\n\nhxuhack:\n\n> If `PTR` remains private, but additional invalid states become possible, then `do_critical_task` cannot be declared safe, correct?\n\nIf `do_critical_task` is crate-public and those additional invalid states are reachable from crate-public safe functions, then yes, `do_critical_task` cannot be safe.\n\nhxuhack:\n\n> If `PTR` is made public (but not to other crates), meaning that additional invalid states could be introduced from outside the module, can `do_critical_task` still be declared safe?\n\nIf the same conditions as above hold, then no, `do_critical_task` cannot be safe. However, if one of those conditions do not hold, then it can be declared safe. It's just a matter of style (crates with multiple contributors like the standard library may prefer to declare it `unsafe` to avoid misunderstandings, but simple crates with a single author might not bother in order to keep call sites readable).",
  "title": "Impact of Static Variables on API Soundness"
}