Re: [rust-dev] State of private

Well... you could consider each member as if it was implemented by accessor method, and control these "methods" even if it was an actual member; of course, also provide a the same syntax for accessing actual members and method-defined-members... but I think this is too far from the current Rust dir

Re: [rust-dev] State of private

On Sat, Nov 9, 2013 at 7:43 AM, Oren Ben-Kiki wrote: > Many thanks for the replies. > > My problem is actually in accessing private methods/members of a struct > defined in a different, but "very closely related" module. It seems @ > nikomatsakis is saying in the

Re: [rust-dev] State of private

I added https://github.com/mozilla/rust/issues/10383 in the hope that enough people would find it useful and it would end up in 1.0 after all :-) In the meanwhile, I'll have to re-think my design to see if I can package all the private members in a separate structure, or something like that. Than

Re: [rust-dev] State of private

On 11/8/13 10:43 PM, Oren Ben-Kiki wrote: Looking at the same thread, I see nobody asked about a possibility of keeping the existing rules, but also adding a "friend" keyword at the module level; that is, if a module foo says "friend mod bar", then the module bar can access any private stuff in t

Re: [rust-dev] State of private

Many thanks for the replies. My problem is actually in accessing private methods/members of a struct defined in a different, but "very closely related" module. It seems @ nikomatsakis is saying in the final text comment of https://github.com/mozilla/rust/issues/82

Re: [rust-dev] State of private

> I just want to know what the state of affairs is. The current state of affairs in terms of visibility and privacy in the languages is "defined and implemented with possible bugs." What's documented in the manual/tutorial is what is intended and currently implemented in the compiler, and if there

Re: [rust-dev] State of private

I find that in several cases I would like to have sibling modules access private members, that is, allow "foo::bar::Bar" access the private members of "foo::baz::Baz", but disallow any code in "qux::*" from accessing these members. The solution to prevent qux::* from accessing privates of bar an

[rust-dev] State of private

I find that in several cases I would like to have sibling modules access private members, that is, allow "foo::bar::Bar" access the private members of "foo::baz::Baz", but disallow any code in "qux::*" from accessing these members. Currently in these cases I am forced to expose as public stuff tha