Fix #2529: explicit protection package #3651

[Kagamin via Digitalmars-d-announce]

On Wednesday, 20 August 2014 at 14:35:31 UTC, Dicebot wrote:
> 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).

If generic implementation is designed to be customized, it 
probably means, it should be widely available for customization, 
like xml document and base64 encoder. Also it's probably a 
logical error if base type is less visible than the derived type.

> 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)

It's ok for packages to exchange public interface, but internals? 
If a subpackage has internals, they are for its usage, and 
consumable functionality should be provided through public 
interface.