>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 <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
