{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreighhvwisd3lzg4tym6vtj3r6jr4rqdt6cfwggtopkzadziiqxy3i4",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mk7hipu5w622"
  },
  "path": "/t/pre-rfc-pub-api-visibility-and-static-enforcement-of-crate-internal-api-boundaries/24184#post_8",
  "publishedAt": "2026-04-24T01:08:59.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "I'm sure this has been discussed before. It would be cool to add an even more general and powerful feature instead.\n\n\n    vis api = vis!(in crate::resources);\n    vis anotherapi = vis!(in crate::resources);\n\n    pub(api) fn foo() {}\n    pub(anotherapi) fn bar() {}\n\n\nThis would completely solve the problem of\n\n> If we later decide to move the `file_api` module to a different location, we would have to update all of the visibility modifiers\n\nAnd, I feel this gives developers a simpler model of visibility than needing to understand `mod` and `#[api]`. Adding another attribute `#[api]` doesn't feel like the most elegant solution here.\n\nGranted, we are adding another keyword `vis` (bikeshedding allowed). And, we will need a syntax for `vis!()`. But, if we call my pre-pre-pre RFC idea here 'Vis Assignments', then it seems that Vis Assignments solve the same problems presented here but better. Happy to discuss. Vis Assignments would actually be pretty neat.",
  "title": "Pre-RFC: `pub(api)` visibility, and static enforcement of crate-internal API boundaries"
}