{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiei6wuusxzulzroskhkcbdpjejrgaukurevpc2qpeojztduygho2a",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3me5oqud2ubg2"
  },
  "path": "/t/private-unsafe-fields-are-a-poorly-motivated-feature/23976?page=2#post_27",
  "publishedAt": "2026-02-06T00:40:36.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "scottmcm:\n\n> I would not make that `new_unchecked` function an `unsafe fn`\n\nI find this a very strange, counter-productive recommendation. I would never do that.\n\nMy reasons have nothing to do with memory safety.\n\nThe reason I'd never do that is that by exposing a safe `new_unchecked` I've just thrown out encapsulation, type-based correctness out of the window. As a user of the number theory crate, when I see a `Prime`, I want to know that no matter what I do (barring language or library UB, obviously), that is going to be a prime. Correct by construction. Make invalid states unrepresentable. I want there to be no way to create a `Prime` that is not a prime.\n\nWhen a user of my crate shows me his binary that produces a `Prime { p: 9 }`, and I can see that his binary doesn't have any `unsafe` blocks, I want to instantly know: aha, obviously my crate has a bug.\n\nBy not marking `new_unchecked` `unsafe`, you've just gotten rid of this whole type-based correctness knowledge. To debug a `Prime { p: 9 }` I now have to study both the library crate and the user crate.",
  "title": "Private unsafe fields are a poorly motivated feature"
}