I was thinking instead of prohibiting the import we add a "protection attribute" to handle this.

Trying to create a concrete example and use "package" shows that package cannot handle it. Instead an attribute ("library") which allowed access if the module belonged to the same top level package would work I believe. eg.

[yourlib/foo.d]
module yourlib.foo;

[yourlib/_foo/_bill/a.d]
module yourlib._foo._bill.a;
library: //access for all yourlib.* module/packages

If a client imports "yourlib/_foo/_bill/a.d" they cannot access anything, yet at the same time "yourlib/foo.d" has access to everything in the yourlib.* tree.

That said, in my concrete example I was using 'version' and 'alias' in "yourlib/foo.d" to select the implementation, which of course then requires access to that implementation from outside the tree, defeating the initial purpose.

Perhaps prohibition is the only solution. Instead of "hidden" could we use the existing protection attributes? eg.

public module foo.bar;    //importable by everyone
protected module foo.bar; //importable by foo.*
package module foo.bar;   //importable by foo.bar.*
private module foo.bar;   //not importable

Or similar.

Regan

Regan Heath wrote:
> 
> Perhaps prohibition is the only solution. Instead of "hidden" could we use  the existing protection attributes? eg.
> 
> public module foo.bar;    //importable by everyone
> protected module foo.bar; //importable by foo.*
> package module foo.bar;   //importable by foo.bar.*
> private module foo.bar;   //not importable
> 
> Or similar.

Call it anything you'd like :) I'm only interested in the feature itself. What you suggest though extends the idea much further, which I like. But looking at your example... I'm thinking this is what you meant:

public module foo.bar.baz;    //importable by everyone
protected module foo.bar.baz; //importable by foo.*
package module foo.bar.baz;   //importable by foo.bar.*
private module foo.bar.baz;   //not importable

So 'protected' modules would be accessible up to the root package, while 'package' modules would be accessible within the same package. Actually,  package protection now extends to subpackages:

module foo.module;
package const int MYINT = 1;

module foo.bar.module;
import foo.module;

// has access to MYINT

So, if we were to apply the same sort of protection to modules, perhaps we should say that a 'package' module could be imported by modules in the same package or in subpackages but not those in super packages, while a 'private' module could only be imported by modules within the same package.