Fix #2529: explicit protection package #3651

[Kagamin via Digitalmars-d-announce]

On Saturday, 23 August 2014 at 10:04:40 UTC, Dmitry Olshansky 
wrote:
> For what its worth I'd _prefer_ std.regex.internal as in my 
> opinion internals got to be well contained. But as discussed, 
> `package` doesn't work this way.

It can be a philosophical matter, but in my experience grouping 
by functionality is genuine, and access is an afterthought, so 
grouping by access doesn't work in the long term, as code 
naturally (spontaneously) groups by functionality. The reason is 
when you maintain code, you traverse it according to 
functionality, because you work with implementation, and 
protection is interface, so protection is ignored. If you add a 
public functionality to internal module (ranges often end up like 
that), you can either just qualify it with public access, as it's 
done in normal modules, or refactor and move it to public module, 
so you end up with logically grouped functionality separated 
between two or more modules, which try to enforce grouping by 
access, while in normal modules you have logically grouped 
functionality in the same module even if they have different 
access. Also you can end up with public functionality in internal 
module, if the member proved to be stable, robust and use case 
for it arises.