Add a friend keyword at the module level

[orenbenkiki]

The current state of the rules allow using re-exports to control accessibility and visibility of functions and types between modules. However, this suffers from two downsides; first, as @nikomatsakis said in his last comment in #8215, it is impossible to use re-exports to control accessibility and visibility of members and methods. Second, "barrier modules" doing re-exports requires tedious boilerplate code and reduces "code locality" (it is hard to tell where a function is accessible just by looking at it - one needs to also trace the re-exports, which are in other modules).

Adding a module level friend keyword would help solving both problems. The idea is that in addition to the existing rules, if a module foo says friend mod bar then the code in the module bar can access any private code of the module foo.

This is different from the C++ friend keyword in that it works at the module level, keeping things simple and in line with the general spirit of the current rules.

[ghost]

I think this is an important little feature which makes structuring your code considerably more comfortable in certain cases. But I'd like to suggest that we'd use the word trust instead of friend, because to me "friend" implies a bi-directional relation: "X is a friend of Y" implies also that "Y is a friend of X". Whereas trust mod bar; sounds like what it actually does, i.e. "Entrust module bar with an access to your private items".

[pnkfelix]

We now need language changes to be written up as RFC's and sent through the RFC process.

Closing; if you want this language change to be considered, please submit it at the RFC repo:

https://github.com/rust-lang/rfcs/