Packages / imports & references between modules

Adam D. Ruppe destructionator at gmail.com
Sat Apr 27 16:30:48 UTC 2019


On Saturday, 27 April 2019 at 16:24:40 UTC, Robert M. Münch wrote:
> I thought that public only applies to the upward chain, not to 
> the same level.

There is no "same level" really (except for the `package` 
protection level); it is just inside the module or outside the 
module for imports.

But I see what you are doing now...

> A/c.d
> 	module A.c;
> 	struct myOtherStruct {
> 		myStruct ms;
> 	}

This will never work in D. The module needs to work by itself. It 
can see public imports from another module it itself imports:

module A.c;

import A; // thanks to this, it can see a `public import A.a;` 
from the A package..


But without that explicit import, it cannot see anything outside 
itself.


You might be able to get away with listing the `public import`s 
in package.d, and then just `import A;` in each individual module 
though.

But it won't just inherit stuff from other modules, like C's 
#include does. A D module is parsed independently of other 
modules.

> works. But this would end up in adding a lot of imports to 
> avoid the "undefined identifier" problem to many files manually 
> and somehow break the DStep workflow.

maybe dstep could automatically add imports to generated files 
too.


More information about the Digitalmars-d-learn mailing list