{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreice4ihpfmf2mf7ck3jb6atqo4vl7fvazk3cxv6lmmuiypp6jclvcm",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mfdfkqg74h22"
  },
  "path": "/t/private-unsafe-fields-are-a-poorly-motivated-feature/23976?page=10#post_186",
  "publishedAt": "2026-02-20T13:36:01.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "tczajka:\n\n> ia0:\n>\n>> Not \"confident\", but otherwise yes.\n>\n> If you're equally confident about both guarantees, why bother stating a separate weaker guarantee at all?\n\nI should have said \"not _only_ confident\". Before all, it's about commitment, responsibility, maintenance, clarity, etc. My problem with confidence, is that it makes it look like it's about trust. This is a consequence of the API choice, not the API choice itself. You pay more attention to your safety properties than your correctness properties. That said, for trivial libraries, it might be simpler to have a single property: correctness. Because the cost of tracking 2 independent ones is not worth it. That's just part of the API choice. For libraries where correctness is highly non trivial, it makes a lot of sense to have simpler safety (possibly only what safe code gives you).",
  "title": "Private unsafe fields are a poorly motivated feature"
}