Need review: explicit package protection

[Steven Schveighoffer via Digitalmars-d]

On Sun, 08 Jun 2014 11:37:04 -0400, Dicebot <public at dicebot.lv> wrote:

> Finally got to cleanup and submit this PR:
> https://github.com/D-Programming-Language/dmd/pull/3651
>
> While proposed change is very small (and backwards-compatible)
> and not worth separate DIP, it is still a language change and
> needs community approval.
>
> Copy of description:
>
> ========================================
>
> Currently there is no way to use package protection attribute
> with deeply nested package hierarchy, forcing to either use flat
> one or public protection. This is one of blocking issues for
> further usage of package.d in Phobos and one of reasons why
> namespace hacks are so popular.
>
> For example, if helpers in std.internal will be marked as
> package, only std.internal will be able to access those, but not
> rest of std. This PR fixes it by allowing package(<pkgname>)
> syntax to explicitly define owning package.
>
> This new syntax will work:
>
> ---
> module std.internal.mod1;
> package(std) void foo() {}
> module std.mod2;
> ---
> import std.internal.mod2;
> void bar() { foo(); }
> ----
>
> Exact semantics can are described by added "protection" tests to
> test/compilable (last commit in this PR).
>
> Plain package behavior is unchanged and thus no breaking changes
> introduced.

Yes, this becomes more crucial with the idea of splitting up a file  
seamlessly with the package.d idiom. A file that already has  
package-accessible functions CANNOT be split up without an improvement  
like this. Given that nothing can utilize unauthorized functions, you can  
only give more access to your own functions, I think this is a worthwhile  
improvement.

-Steve