{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidlqldvccs3lqo3er4jc2gmsz6jpd4kwpalptgtni6bhrwvtjxd6i",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mjviufsrvsi2"
  },
  "path": "/t/pre-rfc-pub-api-visibility-and-static-enforcement-of-crate-internal-api-boundaries/24184#post_5",
  "publishedAt": "2026-04-20T02:48:06.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "@robofinch"
  ],
  "textContent": "It shouldn't block `pub(api)` because, as mentioned, it would become a weak keyword. The set of possible first tokens in a `pub(E)` context I believe are `self`, `super`, and `in` otherwise. If that is the case, then introducing `api` as another should not be ambiguous.\n\nWhile `pub` can be used within a module, the rustc lints documentation suggests that the only reason this isn't a default warning is that it would break too much code right now, and may change. See my reply to @robofinch about `unreachable_pub`.\n\nI'm perfectly happy with replacing #![api] with another way of definining the boundary. I provide some alternatives I came up with off the top of my head in the RFC. While it may be possible to import a module as the name `api`, note that this is unrelated to my suggestion, as the `pub(api)` visibility modifier is not using `api` as a name in the current module scope. There are several potential benefits to having an alternate visibility, such as ensuring that non `pub(api)` items don't escape a module boundary, and to allow for the visibility of an API boundary module and its exported items to be modified with a single visibility at the module definition site.",
  "title": "Pre-RFC: `pub(api)` visibility, and static enforcement of crate-internal API boundaries"
}