Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document the privacy rules for re-exports #1558

Open
mattheww opened this issue Aug 4, 2024 · 0 comments
Open

Document the privacy rules for re-exports #1558

mattheww opened this issue Aug 4, 2024 · 0 comments
Labels
A-visibility Area: visibility and privacy

Comments

@mattheww
Copy link
Contributor

mattheww commented Aug 4, 2024

The following program is rejected:

mod sub {
    fn prv() {}
    pub use prv as renamed;
}

The restrictions which cause this rejection were introduced in rfc136.

I don't think the Reference currently states these restrictions explicitly anywhere.

The current text in visibility-and-privacy.md gives the following basic rules:

Rust allows item accesses in two cases:

  1. If an item is public, then it can be accessed externally from some module m if you can access all the item's ancestor modules from m. You can also potentially be able to name the item through re-exports. See below.
  2. If an item is private, it may be accessed by the current module and its descendants.

Then under "Re-exporting and Visibility" it says:

Rust allows publicly re-exporting items through a pub use directive. Because this is a public directive, this allows the item to be used in the current module through the rules above. It essentially allows public access into the re-exported item.

I think this is most naturally read as saying that the example above is accepted, and that renamed can then be used outside sub. In any case it can't be read as saying that the example's use statement itself is rejected.

There's also the following text in use-declarations.md:

A public use declaration can therefore redirect some public name to a different target definition: even a definition with a private canonical path, inside a different module

I think this indirectly implies the existence of the restrictions.

@ehuss ehuss added the A-visibility Area: visibility and privacy label Aug 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-visibility Area: visibility and privacy
Projects
None yet
Development

No branches or pull requests

2 participants