External Publication
Visit Post

Pre-RFC: `pub(api)` visibility, and static enforcement of crate-internal API boundaries

Rust Internals [Unofficial] April 20, 2026
Source

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.


  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. ↩︎

Discussion in the ATmosphere

Loading comments...