Maybe I'm misunderstanding something, but you don't need to put everything
inside the private module. There's even an example in the manual that does
something like this:
// this is the crate root
mod internal
{
pub fn internal_1() { }
}
pub mod external
{
// public functions here will be available outside the crate
2013/10/10 SiegeLord <[email protected]>
> On 10/09/2013 11:48 PM, Alex Crichton wrote:
>
>> 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.
>>
>
> It wasn't so much that I was balking at the prospect of rewriting my code,
> as it was that the rewrite was ending up so voluminous and roundabout. That
> said, I think I came up with a solution that seems to resonate a bit better
> with me:
>
> pub use mod_a = internal::mod_a::external;
>
> mod internal
>
> {
> pub mod mod_a
> {
> pub struct S { priv m: int }
>
> pub mod external
> {
> pub use super::S;
> impl super::S
>
> {
> pub fn pub_api(&self) -> int { self.m }
> }
> }
>
> pub fn crate_api_2() -> S { S{m: 0} }
> }
> }
>
> It seems to be a pleasant inversion of what was done with the old
> approximate rules, except that you have to root the entire module tree in a
> private module to establish the visibility wall (which is still unfortunate
> as far as documentation goes).
>
>
> -SL
> ______________________________**_________________
> Rust-dev mailing list
> [email protected]
> https://mail.mozilla.org/**listinfo/rust-dev<https://mail.mozilla.org/listinfo/rust-dev>
>
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
