{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiecalqog4lntw3xwxmswwogwlv562sggq3rvjy4fufnnjhw7qz6te",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3me5bds7q4vj2"
  },
  "path": "/t/private-unsafe-fields-are-a-poorly-motivated-feature/23976#post_8",
  "publishedAt": "2026-02-05T20:19:29.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "tczajka:\n\n> Or should `val` be an `unsafe` field here, even though the module doesn't use it for memory safety?\n\nI would respond that the example is poor.\n\nIt should clarify whether \"guaranteed\" is correctness or soundness, and then either\n\n  * make `set_unchecked` _not_ be `unsafe`, or\n  * make `val` be `unsafe`, updating the `new` with a safety comment about why constructing it there is correct\n\n\n\nRight now it's unclear to consumers whether they can soundly do `std::num::NonZero::new_unchecked(your_nz.get())` or not, so even without this feature that should be clarified.\n\n(Similarly, if `set_unchecked` is going to be `unsafe fn` then it should have a `# Safety` comment to state its preconditions.)",
  "title": "Private unsafe fields are a poorly motivated feature"
}