Need review: explicit package protection

[Steven Schveighoffer via Digitalmars-d]

On Wed, 11 Jun 2014 10:09:18 -0400, Jonathan M Davis via Digitalmars-d  
<digitalmars-d at puremagic.com> wrote:

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

I think this is a given. But note that you can write code that "lives" in  
the same package via a module statement today.

i.e., inside mystuff/bar/foo.d:

module std.internal.foo;

-Steve