{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreie7blhlanonzd4uhgsy2u7iceogkbi65jkksd6fieyhig53wgl4s4",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mjviutag5cs2"
  },
  "path": "/t/pre-rfc-pub-api-visibility-and-static-enforcement-of-crate-internal-api-boundaries/24184#post_2",
  "publishedAt": "2026-04-20T02:03:04.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "[1]",
    "↩︎"
  ],
  "textContent": "> Our options are now either to use pub(in super::super), or to use pub(in crate::resources), but these add a lot of verbiage to our source file:\n>\n>\n>     // In src/resources/io/file_api/mod.rs\n>\n>     /// A set of resources that can be read individually.\n>     pub(in crate::resources) struct ResourceSet {\n>       // ...\n>     }\n>\n>     impl ResourceSet {\n>       /// Open a file path to load resources from it.\n>       pub(in crate::resources) fn open(path: &Path) -> Result<Self> {\n>         // ...\n>       }\n>\n>       /// Load a resource with the given ID.\n>       pub(in crate::resources) fn load_resource(res_id: &str) -> Result<Resource> {\n>         // ...\n>       }\n>     }\n>\n\nThere’s another option: `pub(in crate::resources) struct ResourceSet` (or `in super::super`), and use `pub` for associated items. This is what I do; I think it’s cleaner for associated items’ visibility to be controlled by the main item’s visibility[1]. I know there’s an issue open about adjusting the `unreachable_pub` lint (or something like that) to treat associated items differently.\n\n* * *\n\n  1. Well, more precisely, “the visibility of associated items intended to have the same visibility as the main item”, I don’t mean to say that none of my associated items are private. ↩︎\n\n\n",
  "title": "Pre-RFC: `pub(api)` visibility, and static enforcement of crate-internal API boundaries"
}