DIP16: Transparently substitute module with package

[Jonathan M Davis]

On Saturday, March 31, 2012 06:23:32 Chris NS wrote:
> I'm pretty impressed with the idea, and look forward to its
> implementation, but I do have one question.  How does this affect
> (if at all) the implicit "friend" relationship of declarations?
> Since package "foo.bar" is treated as a single module, do the
> classes in "foo/bar/alpha.d" and "foo/bar/beta.d" have access to
> each other's private members?
> 
> I'm not sure whether I favor them losing or keeping their
> "friend" status.

It wouldn't affect any of that. If something is marked private, then everything 
within its module has access to it, but nothing else does. If something is 
marke package, then everything within that package has access to it, but 
nothing else does. By splitting up foo.bar into foo.bar.alpha and 
foo.bar.beta, you've created a package. Everything private in either 
foo.bar.alpha is inaccessible to everything in foo.bar.beta and vice versa. If 
you want it to be accessible to the other module, then mark it as package.

Anything which was private in foo.bar, was an implementation detail of 
foo.bar, and nothing using foo.bar cared. Anything which is private or package 
in foo.bar.alpha and foo.bar.beta is an implementation detail, and nothing 
using anything in foo.bar cares. The whole point of this proposal is to make 
it seemless for the users of a module when a module is split into a package. 
And the implementation details of a module are irrelevant to that. It's just 
the public and protected stuff which matters.

- Jonathan M Davis