better visibility control

[jesse99]

It's very annoying that the only options for controlling visibility are public (to everyone) and private (to a module). C# has a nifty third option internal: (to an assembly).

If rust is moving towards using pub and priv to control visibility perhaps something like a crate keyword can be added so library authors have the freedom to structure their code as they like without being forced to make visible items which are properly of internal use.

[graydon]

We actually worked reasonably hard to make it possible to simulate this via pub and priv. The technique is to make sub-modules within your crate priv (which will, eventually, be the default for unqualified mods) and to then write some pub import directives in the outer crate-level module, to re-expose the portions you want to be visible-outside-the-crate. That's all we're going to do for now; if it proves awful in practice we can reopen this, but for now I'm closing it.

[jesse99]

This has been a constant source of frustration for many months now (an example of how to structure a non-trivial library would be very helpful). The old model wasn't documented especially well and the new pub and priv stuff doesn't appear to be documented at all.

pub import doesn't compile with the latest rust and pub only seems to work with items so I can't make an identifier public in any case. I tried pub use foo::{bar}; which did compile but didn't seem to make bar visible from the module that did that.

[brson]

Reopening for @jesse99. I can certainly sympathize. Visibility and resolution rules have always been hazy, and even for 0.4 there's going to be a lot that isn't settled.

I will note that crate level visibility is similar to the issue that the rust test driver has calling private tests, and the test runner actually has a super-secret attribute to allow it to break visibility rules to do it.

[jesse99]

This seems to be working as of rust 0.4. However wasn't able to fully test it because of #3781.

[jesse99]

I've been able to use stuff like pub use blah::*; to control what is visible from the top level of my crate which is cool.

However I still don't know how to a write an item that is visible within a crate but not outside of it. I can create a private sub-module and the parent module can control what is exported from the sub-module but afaict it's exported to everyone.

Here's a motivating example. Fairly often I have some complex code with a very simple public API, often just a single function. I'd like to structure the code however I want. Maybe it's complex enough that I want to spread the implementation across multiple modules. Or maybe I want to split the code and unit tests into different modules. But as far as I know, I can't do any of this without making my implementation visible to everyone.

Perhaps I am missing something but that is highly unsatisfactory. I really don't want to make my implementation details visible to clients, but I also really don't want to be forced into writing gargantuan modules.

[graydon]

I apologize if I'm suggesting something you're already doing, but does this not do what you want?

pub mod proj {

    // This is the sole publicly-visible function: proj::entry_fn.
    pub use impl::entry_fn;

    mod impl {
        // All your implementation items are in here.
        pub use stuff::*;
        pub use things::*;
        pub mod stuff;
        pub mod things;

        pub fn entry_fn() { ... }
        pub fn other_fn1() { ... }
    }
}

[jesse99]

I don't think so. It comes down to logical versus physical organization. From a logical standpoint the above is fine. But it doesn't seem to address the physical organization of the code (i.e. the files).

[catamorphism]

I'm not feeling like we're going to change this. Reopen if you have a concrete proposal for change.

[bblum]

Reopening. I would like the rule to be: "pub items in a non-pub mod are visible to the rest of the crate, but not visible to users outside the crate". This is necessary to finally seal the leakiness of the select trait abstraction, cf #5160.

Hmm well, it's not strictly necessary, as all of the stuff that refers to what I wish to keep private could just be concatenated into the same file. But having it that way would mandate having enormous files which could otherwise be split apart.

[alexcrichton]

@bblum, would the rules in #8215 be sufficient for your needs?

[bblum]

Yes, thank you.