+1 to dealing this is one way or another.

Another issue that dovetails with this is that unit tests are typically put
in submodules but can't see private members in their parent.  I often want
to write tests for private helpers or check invariants that aren't visible
in the public interface.  AFAICT I either need to skip those tests or break
with conventions. (Am I missing something?)

Allowing submodules to see their ancestor's private items would fix this
but feels too sweeping to me. How about something like C++'s friend
declaration where you'd be able to declare which modules can see your
module's private items?
Hello,

I'd like to get people's opinions about crate local visibility. I feel that
the way the public / private scope is divided now is encouraging making
either too much code public or creating very large modules. If crate local
visibility is not doable / too complex, then I'd ask to at least allow
inner modules access to their ancestors' private items.

What do you think? Is it a good idea?

Thanks for reading,
Dov

_______________________________________________
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

Reply via email to