Fix #2529: explicit protection package #3651

[Kagamin via Digitalmars-d-announce]

On Wednesday, 20 August 2014 at 20:39:06 UTC, Chris 
Nicholson-Sauls wrote:
> module foo.bar.one;
> module foo.bar.internals; // package-protected utilities
> module foo.bar.subpkg.two;
> module foo.bar.subpkg.internals; // package-protected utilities
>
>
> and module 'two' cannot access the 'bar' utilities.

Really? Looks like a bug. You'd better check if it's intended to 
work that way.

> This is needlessly limiting, forcing design choices that should 
> not be dictated by the ability/inability to separate public and 
> private API.  It also precludes many valid and good uses of 
> nested package.d modules.

If some thing is used in entire foo.bar package, then it's 
foo.bar's internal, not foo.bar.subpkg's internal. I think, it's 
natural when the wider the thing is used, the higher in hierarchy 
it sits.

> I really don't see any equally strong counter-argument.  But 
> then, I've wanted this exact fix for literally years now.

I don't really see, what it blocks.

> It also is not limited to internal utility modules.  It can be 
> useful for systems that select at compile time from one of a 
> number of system-specific implementations of a given 
> interface/api.  It can be useful for granting privileged access 
> to certain api's and/or resources to specific module(s).  An 
> example being: grant access to unsafe but versitile data 
> manipulators solely to the subpackage containing the loaders.

If those manipulators are used solely in loaders subpackage, they 
should belong to that package. Though I don't really see a 
problem here: there was an implementation of xml document, which 
allowed unsafe (but fast) specialization, which was believed to 
be useful for public usage. It fits well into D philosophy that 
safe things should be available by default and unsafe/fast things 
should be possible.