Need review: explicit package protection

[Jonathan M Davis via Digitalmars-d]

On Sun, 08 Jun 2014 15:37:04 +0000
Dicebot via Digitalmars-d <digitalmars-d at puremagic.com> 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.

I would be inclined to argue that this should be done in a way that restricts
its use to subpackages of the package that it's being added to, otherwise this
kind of breaks the whole idea of package and becomes something closer to C++'s
friend. So, std.internal.foo could have symbols marked with package(std), but
mystuff.bar.foo couldn't, because it's not a subpackage of std.

- Jonathan M Davis