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