(hit send by mistake)
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
use internal; // pub functions in internal are now usable here
pub fn pub_api_1() { internal::internal_1() }
}
2013/10/10 Andrei de Araújo Formiga <[email protected]>
> 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