Summary: 'package' access qualifier should allow access to sub-
           Product: D
           Version: 1.037
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: spec
          Severity: enhancement
          Priority: P2
         Component: DMD

Currently, a symbol declared as package in "a.b" is only accessible to other
modules in "a", such as "a.c" and "a.d".  But it is not accessible from

The language spec is somewhat unclear on this:

"Package extends private so that package members can be accessed from code in
other modules that are in the same package. This applies to the innermost
package only, if a module is in nested packages. "

What I find unclear is "other modules in the same package."  I see "a.sub.x" as
in the same package as "a.b", since they're both in "a".  

What would this be useful for?  Well as a practical example, I've been working
on the new implementation of MiniD for several months, and as the codebase has
grown, I've accumulated more and more modules.  Now that I have close to 50
modules in one package, I'd like to put them in sub-packages of related

The problem is that there is a small set of "universal" functionality which is
needed by the entire library but which I don't want to be accessible from
outside the library.  I can't make it private since then it won't be accessible
from other modules in the library.  I can't make it public because then it
would be accessible from outside the library.  So I'm stuck with package, but
the problem with that is that only modules with the _exact_ same package prefix
as the common functionality can access it.  Thus, all of my modules are forced
into the same package.

What I am proposing is that the "package" qualifier's meaning of "other modules
in the same package" be defined to be "other modules in the same package,
including those in subpackages."  This does not actually even require a spec
change, since this new behavior is consistent with what is stated.  It also
does not break any code, is a simple fix, and without it, I can see a lot of D
libraries and programs being forced into this kind of one-level hierarchy.


Reply via email to