As I think was mentioned on IRC, sadly there wasn't a set of well defined privacy rules in place beforehand. What I've been able to gather is that they were a rough approximation of what was desired at one point in time, but more pressing matters led to them never really getting refined to where they were well documented and well tested.
What you've described above is all correct and intended behavior. I can imagine that it's difficult to port old libraries using the old behavior, but the idea of the new rules is to as naturally as possibly expose the visibility of an item. As an an ancestor of an item, you would naturally be known to expect how your parents were implemented (because you probably implemented them), so it's perfectly find for you to reach into their private items. Otherwise, you're never expected to have knowledge of the implementation details, so all private items are hidden from you otherwise. You're correct that one of the consequences is that any crate-local apis must be rooted at the top of the crate. It's not true that they all need to be in one module, however, they can all be in separate private sibling modules. >From redoing the rules, I came to much prefer this idea of visibility to different rules for inter and intra crate apis. Noe only do the same set of rules apply for all types of visibility everywhere, but I also think that these apis are more expressive. Now the rule of thumb is basically "make it public if this is an api for a parent consumer". I realize that privacy has been a tricky topic in the history of rust, and I tried my best to write up as much documentation as I could on the topic in the manual, but if there's anything you think needs clarification, please let me know! It would be a shame common practice to be "make everything public" and then read up on whether it should actually be public or not. That being said, if the new system is indeed more of a pain then it's worth, then we're still pre-1.0 so we have a little wiggle room to tweak things as we see fit. On Wed, Oct 9, 2013 at 3:26 PM, SiegeLord <[email protected]> wrote: > I'll start right away with an example. Consider this crate that could have > been written using the old privacy rules: > > pub mod mod_a > { > pub struct S { priv m: int; } > > impl S > { > pub fn pub_api(&self) -> int { self.m } > } > > mod internal > { > use super::S; > impl S > { > /* This one doesn't actually work due to bugs */ > pub fn crate_api_1() -> S { S{m: 0} } > } > > pub fn crate_api_2() -> S { S{m: 0} } > } > } > > Under the old privacy rules, items were accessible within a crate if they > were pub'd, regardless of the intervening privacy. Note that crate_api_1() > and crate_api_2() can only be used within the crate. Under the new privacy > rules, this sort of looks like this: > > mod internal > { > pub struct S { priv m: int; } > > impl S > { > pub fn pub_api(&self) -> int { self.m } > } > > pub fn crate_api_2() -> S { S{m: 0} } > } > > pub mod mod_a > { > pub use internal::S; > } > > The general idea is that you have a top-level, private module which contains > the crate-scoped API. Note that I don't think you can even write crate_api_1 > anymore. Also note how the public API moved inside the internal module: in > fact, pretty much everything is now placed inside it, and the public API is > now re-exported elsewhere (reminiscent of the old export lists). If you > weren't planning to have crate-local API, then you'd really have to > restructure your code to support it... so much so, that it might be prudent > to code as if you had crate-scoped API even if you don't (yet). > > Is my analysis incorrect? Is there a way to write crate_api_1 (i.e. a > crate-scoped method) ? Is there a way to avoid moving the entire code base > inside the 'internal' mod? > > One last note... since the new privacy rules don't mention crates, this > problem becomes a bit more general, i.e. it's very tricky to isolate a > particular API to a sub-tree of modules. I feel like it's almost simpler to > just make everything public and rely on documentation or place everything in > a single module. > > -SL > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
