Need review: explicit package protection

[Dejan Lekic via Digitalmars-d]

On Sunday, 8 June 2014 at 15:37:06 UTC, Dicebot 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.

+1
Definitely worth merging!

However, package module still have few issues.

Issue #1)

Few times I asked myself "what am i importing, package or a
module?" when I used package module, so whenever I import a
package, I add a short comment, something like:

// assuming I have
import foo.bar.baz; // package import

Issue #2)
Package module is not possible in projects with flat structure
(projects whose authors did not reserve directories for packages.

Example:
Imagine developer has *all* his D sources in
/home/dejan/src/d/myawesomeproject because he does not like big
directory structures. Say his project has two packages foo.bar
and foo.baz . And has following files in his project directory:

tools.d // module foo.bar.tools;
control.d // module foo.bar.control;
screen.d // module foo.baz.screen;
window.d // module foo.baz.window;
package.d // can be only one 'package.d' within a single
directory!
main.d

So, we have to rename the file into something else. Most likely
developer would try with foo_bar_package.d and foo_baz_package.d,
but it is not possible to do module foo.bar; // conflicts with
previous modules
or
module foo.bar.package; // package is a reserved word

So in this case package module is not possible, and developer has
to use classic approach if he/she wants to import all modules
within foo.bar or foo.baz packages.