{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiauvndgxeodbmgivfyae77qanzs65tvatjcr4c355vpwnc3f5qj4a",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkjddkfay222"
  },
  "path": "/t/pre-rfc-pub-api-visibility-and-static-enforcement-of-crate-internal-api-boundaries/24184#post_10",
  "publishedAt": "2026-04-27T23:13:45.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "Your last paragraph brings up many cool questions, for which in my mind there are clear derivable answers.\n\nBut I'm still confused. What problem does 'Vis Assignments' not solve again? The \"boundary enforcement\" aspect is simply a question of visibility and documentation, no? I claim that 'Vis Assignments' enforces all visibility requirements. If you mark as 'pub(api)', you will not be able to export beyond the visibility of the 'vis(in crate::resources)', and normal visibility rules apply as if you textually replaced `pub(api)` with `pub(in crate::resources)` as this is just an alias. About visibility of visibilities, I believe an initial implementation could disregard this by only allowing `pub(self) vis api = ...` which is identical to `vis api = ...`, and as such visibilities cannot form the public API of a crate.",
  "title": "Pre-RFC: `pub(api)` visibility, and static enforcement of crate-internal API boundaries"
}