Pre-RFC: `pub(api)` visibility, and static enforcement of crate-internal API boundaries
Rust Internals [Unofficial]
April 20, 2026
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:
// In src/resources/io/file_api/mod.rs /// A set of resources that can be read individually. pub(in crate::resources) struct ResourceSet { // ... } impl ResourceSet { /// Open a file path to load resources from it. pub(in crate::resources) fn open(path: &Path) -> Result<Self> { // ... } /// Load a resource with the given ID. pub(in crate::resources) fn load_resource(res_id: &str) -> Result<Resource> { // ... } }
There’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.
- 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. ↩︎
Discussion in the ATmosphere