It is not clear to me how to apply lexical-based privacy rules to method calls, though I am not opposed. How can we determine if the module where the method is declared is exported? I guess that the idea is simply to climb the module hierarchy, checking that each module between the declaration of the method and some ancestor of the call site is declared as public?
It is however also possible for modules to be publicly exported via `pub use` (that was part of the original design of the module system, to permit `pub use` to present a set of "public modules" that is different from the private module hierarchy). Related thread: https://github.com/mozilla/rust/issues/8215#issuecomment-25420622 Niko On Mon, Sep 30, 2013 at 02:36:01PM -0700, Alex Crichton wrote: > From what I've seen, privacy is tricky enough as-is, so I think we > should try to avoid new rules and new keywords. That being said, this > may be possible by just actually applying the rules to implementations > as-is. > > Currently, I believe the privacy of a method is calculated by: "is the > method itself private or not?" and that's it. Arguably we should be > looking at the ancestry of methods as well. If we look at all > ancestors, then you could have pub fns inside priv modules which would > only be usable to your own crate (because they're in your ancestry). > > I'm not sure if the privacy of functions and methods is a relic of a > buggy implementation or performed on purpose, though, so I'd want to > talk it over a bit more before we decide to do something like this. I > do agree, though, that it would be nice to have private functions > scoped to a chunk of the module hierarchy instead of perhaps just one > module. > > On Fri, Sep 27, 2013 at 9:44 PM, SiegeLord <slab...@aim.com> wrote: > > Given the proposed privacy resolution rules ( > > https://github.com/mozilla/rust/issues/8215#issuecomment-24762188 ) there > > exists a concept of crate-scope for items: these can be used within the > > implementation of the crate, but are inaccessible from other crates. This is > > easy to do by introducing a private module: > > > > mod private > > { > > pub fn crate_scoped_fn(); > > pub trait CrateScopedTrait; > > pub struct CrateScopedStruct; > > } > > > > It's not clear to me whether or not this is possible (or whether it should > > be) for non-trait implementations. Right now, if I do this: > > > > pub struct S; > > mod private > > { > > impl super::S > > { > > pub fn new() -> super::S { super::S } > > pub fn crate_local_api(&self) -> {} > > } > > } > > > > I find that the associated function can't be used at all within a crate or > > cross crate (issue #9584), while the method resolves in both cases, but does > > not link cross-crate. What should happen in this case? I'd prefer for the > > function and method to resolve within a crate, but not cross crate. > > > > Notably, this is not how trait implementations work today, as those are > > resolved by looking at the location/privacy of the trait and not the > > implementation. I think crate-scoped methods and associated functions are > > very useful though, and it's worthwhile to have a different rule for them. > > > > Or maybe there should be an explicit keyword for the crate scope and not > > bother with these bizarre privacy rules. Or maybe I am missing an alternate > > way to accomplish this? > > > > -SL > > _______________________________________________ > > Rust-dev mailing list > > Rust-dev@mozilla.org > > https://mail.mozilla.org/listinfo/rust-dev > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
