Fix #2529: explicit protection package #3651

[Dicebot via Digitalmars-d-announce]

On Wednesday, 20 August 2014 at 14:25:59 UTC, Kagamin wrote:
> If some utility is internal to std.package1 an used in the 
> entire std.package1, shouldn't it sit in std.package1? Why push 
> it to subpackage?
>
> std.package1.module1
> std.package1.module2
> std.package1.internal <- package1's internals go here
> std.package1.subpackage.module1
> std.package1.subpackage.module2

It may semantically belong to subpackage but still needs to be 
available to package1, something not uncommon in templated code 
(subpackage is generic implementation, package1 is specialization 
that still needs access to non-public functions).

Also you seem to imply that "internal" is always small tightly 
coupled module which is hardly true for any higher level 
functionality. So in practice it will be more like this:

std.package1.module1
std.package1.module2
std.package1.internal1
std.package1.internal2
...
std.package1.internal20

Not really encouraging..

What you propose is effectively prohibiting to use packages to 
organize your code and requiring to design your module hierarchy 
based on desired protection relations, not other way around. I 
think it is conceptually wrong approach and unnecessarily 
restrictive compared to overall D design principles (no single 
"true" way of doing things)